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aggregating  individual  units  into  battalions  and  groups.  The  system  was 
implemented  on  a  VAX  11/785  computer  using  the  PROLOG  programming 
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I.  INTRODUCTION 


A.  LOGISTICS  PLANNING 

The  focus  of  this  paper  is  the  logistics  planning  associated  with  corps 
contingency  planning  for  the  US  Army.  A  US  Army  corps  is  a  flexible 
organization  tailored  to  meet  a  specific  mission.  The  corps  organization  normally 
consists  of  two  to  five  combat  divisions;  some  other  combat  and  combat  support 
units;  and  finally  the  logistics  units  needed  to  support  the  corps*.  Logistics 
planning  for  the  corps  begins  once  an  estimate  has  been  made  regarding  the  types 
and  numbers  of  combat  and  combat  support  units  needed  to  perform  the 
operation.  With  this  knowledge  and  other  mission  characteristics  ,  the  logistics 
planner  must  determine  the  logistical  requirements  of  the  force  and  also  the  types 
and  numbers  of  logistics  units  capable  of  providing  the  support.  [Ref.  l] 

Development  of  the  logistical  force  to  support  a  corps  operation  is  a  complex 
matter.  Although  there  are  some  general  guidelines  on  how  to  do  this  planning, 
there  is  no  specific  formula  or  algorithmic  solution  to  the  problem.  Quantitative 
factors  such  as  the  amount  of  personnel  and  equipment,  short  tons  of  supplies  to 
be  moved  and  handled,  and  the  distances  between  military  units  must  all  be 
considered.  In  addition  to  quantitative  factors,  more  subjective  factors  must  be 

‘The  term  logistics  units  when  used  in  this  thesis  refers  to  the  supply,  maintenance  and 
petroleum  companies  normally  assigned  to  support  groups  in  a  corps.  More  detailed  information  is 
contained  in  [Ref.  1]. 


considered  e.g.,  thi  availability  and  reliability  of  local  civilians  in  the  area  of 
hostilities  that  may  be  available  to  augment  the  logistic  force. 

Development  of  logistics  plans  is  further  complicated  because  the  needed 
expertise  is  seldom  concentrated  in  any  one  or  even  a  few  individuals.  Even  when 
the  information  is  concentrated  in  a  small  group  of  military  staff  officers,  the 
transient  nature  of  military  service  makes  keeping  this  base  of  knowledge  intact 
virtually  impossible. 

B.  EXPERT  SYSTEMS 

The  primary  emphasis  of  this  thesis  is  to  explore  the  feasibility  of  using  an 
expert  systems  approach  to  assist  in  the  logistical  planning  domain.  Expert 
systems  are  capable  of  using  expert  knowledge  to  attain  high  levels  of  performance 
in  a  narrow  problem  domain  e.g.,  the  determination  of  the  logistical  units  to 
support  a  military  operation.  Expert  systems  also  use  information  obtained  from 
experts  in  an  intelligent  way  to  perform  some  task  normally  associated  with 
human  experts.  The  potential  arrangements  of  various  logistics  units  to  support 
corps  forces  is  quite  large.  Some  method  of  transferring  the  procedures,  strategies 
and  rules  used  by  experts  into  an  expert  system  to  determine  logistical 
requirements  could  be  valuable.  [Ref  2j 
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C.  CURRENT  EXPERT  SYSTEMS  APPLICATIONS 

There  are  currently  many  examples  of  expert  systems  in  use  in  both  the 
commercial  and  military  sectors.  XCON  for  example,  is  an  expert  system  used  to 
configure  VAX  computer  components  into  systems  for  Digital  Equipment 
Corporation.  It  is  capable  of  taking  a  customer  purchase  order  and  determining 
the  components  needed  to  ensure  the  order  is  filled  with  a  system  that  is  both 
consistent  and  complete.  IMACS,  a  system  used  in  a  manufacturing 
environment,  takes  a  customer  order  and  produces  a  rough  plan  from  which  an 
estimate  of  resource  requirements  for  the  order  is  prepared.  PROSPECTOR 
helps  geologists  evaluate  the  mineral  potential  for  a  region.  TATR  is  used  by  the 
Air  Force  to  assist  planners  in  developing  plans  to  attack  enemy  airfields.  [Ref.  2] 
Besides  the  demonstrated  use  of  expert  systems  in  real  operating 
environments,  there  are  some  important  characteristics  of  expert  systems  that 
make  them  attractive  to  the  logistics  planning  problem.  First  of  all,  the 
development  of  the  system  will  encapsulate  a  body  of  knowledge  concerning 
logistics  planning  into  an  automated  system.  This  will  provide  a  corporate 
knowledge  base  of  how  experts  in  the  field  of  logistics  planning  resolve  problems. 
As  discussed  above,  the  transient  nature  of  military  service  makes  keeping  a 
knowledgeable  group  of  experts  together  for  a  very  long  time  virtually  impossible. 
The  expert  systems  approach  to  the  problem  can  ensure  institutional  memory  is 
retained.  Another  useful  feature  is  that  expert  systems  can  be  capable  of 
explaining  their  actions.  Very  few  people  are  willing  to  blindly  accept  any 


recommendation  without  some  understanding  of  why  a  particular 
recommendation  was  made.  Finally,  an  expert  system  can  be  adapted  very  easily 
to  provide  training  to  new  personnel  responsible  for  logistics  planning. 

D.  SCOPE 

The  scope  of  this  thesis  is  to  determine  the  feasibility  of  using  an  expert 
system  to  perform  logistics  planning.  The  methodology  used  to  determine 
feasibility  is  as  follows: 

-  An  analysis  of  the  logistics  planning  problem  was  made  to  gain  a  better 
understanding  of  the  key  tasks  associated  with  the  problem  domain. 
Discussion  of  how  the  logistics  planning  problem  is  currently  performed  is 
contained  in  Chapter  II. 

-  A  prototype  was  designed  and  implemented  to  perform  logistics  planning. 
Specifically,  the  prototype  develops  the  two  support  groups  for  a  corps, 
support  command.  Figures  1.1  through  1.3  provide  an  example  of  a  typical 
support  command  with  two  support  groups.  The  support  groups  represent 
the  major  logistical  elements  of  the  corps  and  as  such  are  a  representative 
subset  of  the  problem  domain.  Chapter  III  contains  discussion  on  the  design 
and  implementation  issues. 

-  An  analysis  of  the  prototype  was  performed  by  some  limited  testing.  The 
results  of  the  tests  are  discussed  in  Chapter  IV. 

-  Finally,  the  recommendations  and  conclusions  regarding  the  feasibility  of 
using  an  expert  system  in  the  logistics  planning  environment  are  discussed  in 
Chapter  V. 


Note:  All  elements  in  this 
column  are  company-sized 
units . 
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Figure  1.3  Support  Group  2 
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II.  BACKGROUND 


A.  PURPOSE 

The  purpose  of  this  chapter  is  to  provide  a  better  understanding  of  the  key 
concepts  of  logistics  force  planning  that  must  be  understood  prior  to  developing  a 
prototype  expert  system. 

B.  LOGISTICS  REQUIREMENTS 

The  fundamental  basis  for  all  logistics  planning  is  the  notion  of  consumption 
factors.  Consumption  factors  are  based  upon  empirical  data  obtained  from 
previous  wars,  exercises  and  simulations.  Consumption  factors  express  the 
anticipated  consumption  for  a  particular  class  of  supply  that  will  be  consumed  per 
soldier  per  day  [Ref.  l].  Although  there  are  ten  categories  of  supplies,  the  most 
important  categories  are  shown  in  Table  2.1.  Using  these  factors,  the  gross  daily 
requirements  for  various  supply  categories  can  be  estimated  by  taking  the  product 
of  the  personnel  strength  of  the  supported  force  and  the  applicable  consumption 
factor.  The  gross  requirements  are  then  normally  converted  to  short  tons. 

The  same  methodology  used  to  determine  daily  supply  requirements  can  be 
extended  to  estimate  the  daily  supply  distribution  requirements  and  also  the 
storage  requirements.  Daily  supply  distribution  requirements  are  the  amount  of 
supplies  that  must  be  distributed  by  logistics  units  to  the  supported  force  each 


TABLE  2.1  CONSUMPTION  RATES 


Consumption  Rates  (Pounds  per  man  per  day) 

Supply 

Consumption 

Class 

Class 

Rate 

Description 

I. 

6.7 

Subsistence  Items 

II. 

3.3 

Clothing  and  Individual  Equipment 

III. 

47.8 

Petroleum  Products 

IV. 

8.8 

Construction  Materiel 

V. 

31.3 

Ammunition 

VI. 

3.2 

Personal  Items 

VII. 

4.3 

Major  End  Items 

VIII. 

0.4 

Medical  Items 

IX. 

1.52 

Repair  Parts 

day.  Daily  supply  distribution  requirements  are  equivalent  to  the  daily  supply 
requirements  since  the  logistics  force  will  be  expected  to  distribute  the  amount  of 
supplies  consumed  each  day  by  the  force.  The  logistics  force  is  also  responsible 
for  maintaining  a  certain  level  of  stockage  to  compensate  for  the  order  and  ship 
times  associated  with  replenishing  its  supplies.  The  corps  logistics  force  is 
authorized  to  maintain  a  certain  level  of  stockage  which  is  expressed  in  days  of 
supply.  Storage  requirements  are  the  product  of  daily  requirements  and  the 
authorized  days  of  supply. 

It  is  important  to  note  that  the  consumption  rates  in  Table  2.1  are  not 
absolute  constants.  Consumption  rates  are  situationally  dependent.  For  example, 
the  requirement  for  clothing  will  substantially  increase  in  a  cold  environment  or  in 
an  environment  where  chemical  agents  are  being  used  by  the  enemy  forces.  The 
logistics  planner  must  consider  these  situational  characteristics  and  make 
appropriate  adjustments  to  the  consumption  factors. 


C.  LOGISTICS  UNIT  SELECTION 

Logistics  units  are  designed  to  perform  a  specific  functional  service  such  as 
storage  and  issue  of  a  particular  supply  category  e.g.,  petroleum.  The  logistics 
units  available  to  provide  various  services  have  a  capability  to  provide  a 
particular  service  per  time  interval.  For  example,  a  supply  and  service  company 
can  provide  rations,  clothing,  construction  materiels  and  petroleum  for 
approximately  8000  non-divisional  troops  per  day.  Some  other  unit  capabilities 
are  more  specific,  e.g.,  a  petroleum  supply  company  is  described  as  having  the 
capability  to  provide  bulk  storage  for  approximately  one  million  gallons  of 
petroleum.  [Ref  l] 

The  logistics  planner  must  first  review  the  requirements  discussed  previously 
to  determine  the  types  of  logistic  units  needed  by  the  force.  Then  he  must 
determine  the  numbers  of  each  type  of  unit  needed  to  provide  the  necessary 
capability  to  support  the  logistics  requirements. 

Unfortunately,  the  process  of  determining  logistics  units  is  not  as  algorithmic 
as  the  above  discussion  suggests.  Often  there  is  not  a  specific  formula  to 
determine  the  number  of  logistics  units  needed.  Frequently,  allocation  rules  may 
only  state  that  a  corps  force  normally  has  a  certain  number  of  a  particular  type  of 
unit.  Frequently,  rules  for  allocating  units  may  even  conflict  with  one  another  by 
recommending  different  quantities  for  the  same  type  of  unit.  This  suggests  that 
some  form  of  conflict  resolution  must  be  used  to  select  the  best  recommendation. 
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Besides  general  allocation  guidance,  the  logistic  planner  generally  has 
established  some  general  heuristics  concerning  minimum  requirements  for  a 
particular  type  of  unit.  For  example,  the  general  allocation  rules  may  indicate  a 
daily  supply  requirement  for  a  particular  supply  category  falls  well  below  the 
daily  capability  of  a  particular  unit  responsible  for  that  item.  Despite  the 
shortfall,  a  minimum  of  one  unit  must  be  present  to  provide  the  service  even  if 
the  demand  is  quite  small.  Another  area  involves  the  need  to  have  a  certain 
amount  of  redundancy  in  the  logistics  structure.  It  may  be  desirable  to  have  at 
least  two  of  a  particular  kind  of  unit  in  the  event  that  one  unit  is  degraded  as  a 
result  of  combat  conditions  even  though  one  unit  may  be  sufficient  to  meet  the 
expected  workload.  Finally,  there  may  be  a  need  to  provide  a  service  at  very 
dispersed  geographical  sites.  Even  though  one  unit  may  be  capable  of  providing 
the  required  requirement  at  a  centralized  location,  there  may  be  a  need  for  the 
service  at  two  sites  and  one  unit  cannot  be  partitioned  into  two  effective  units 
capable  of  operating  at  both  locations. 

Finally,  the  logistics  planner  may  have  some  very  precise  knowledge  about  the 
number  of  units  needed  on  the  basis  of  some  existing  plans  that  have  been 
scrutinized  closely  by  way  of  simulation  or  perhaps  have  been  validated  on  the 
basis  of  actual  use.  In  this  case  actual  data  may  indicate  the  need  for  a  specific 
type  and  quantity  of  units  and  invalidate  more  general  planning  rules. 


D.  CHAIN  OF  COMMAND 


After  the  numbers  and  types  of  logistics  units  have  been  determined  the 
logistics  planner  is  still  faced  with  the  need  to  provide  command  and  control  by 
establishing  a  chain  of  command.  For  example,  company-sized  units  must  first  be 
allocated  to  battalions  and  battalions  are  then  normally  allocated  to  two  support 


groups. 

There  are  two  basic  strategies  the  logistics  planner  may  use  to  develop  the 
chain  of  command  for  the  proposed  force.  For  the  purpose  of  discussion,  assume 
the  unit  requirements  listed  in  Table  2.2  are  needed  to  support  the  logistics  force. 
The  allocation  methods  used  to  distribute  these  units  are  discussed  below. 


1.  Mixed  Strategy 

Logistics  units  are  classified  in  two  ways.  The  first  is  the  general 
classification  according  to  the  unit’s  functional  mission  e.g.,  supply.  The  second 
classification  is  the  unit's  specialized  support  role  indicating  whether  the  unit  is  a 
general  support(GS)  or  a  direct  support(DS)  unit.  Direct  support  units  provide 
support  directly  to  customers  and  are  analagous  to  retail  activities  in  the  private 


sector.  General  support  units  support  direct  support  units. 


TABLE  2.2  UNIT  REQUIREMENTS 


Estimated  Unit  Requirements 

Unit  Description 

Functional  Area 

Level  of  Support 

Supply  &  Service 
Field  Service 

General  Supply 

Supply 

Supply 

Supply 

Direct  Support 
General  Support 
General  Support 

Quantity 

4 

1 

1 


The  mixed  strategy  provides  a  chain  of  command  by  organizing  units  into 


battalions  on  the  basis  of  functional  mission  only  e.g., supply.  Hence  battalions 
have  a  mix  of  direct  support  and  general  support  units.  This  arrangement 
provides  a  more  flexible  battalion  but  it  may  also  complicate  the  mission  of  the 
battalion  by  not  focusing  attention  to  a  more  specific  mission.  The  units  listed  in 
Table  2.2  are  displayed  in  Figure  2.1  using  the  mixed  strategy. 

2.  Pure  Strategy 

The  pure  strategy  provides  a  chain  of  command  by  going  one  step  further 
than  the  mixed  strategy  discussed  above.  It  organizes  units  on  the  basis  of 
functionality  as  well  as  the  units  capability  i.e.,  DS  or  GS.  This  results  in 
battalions  with  a  functional  mission  of  pure  direct  support  or  general  support. 
The  units  listed  in  Table  2.2  are  displayed  in  Figure  2.2  using  the  pure  strategy. 


Figure  2.1  Chain  of  Command  I’sing  Mixed  Strati  g\ 


Figure  2.2  Chain  of  Command  Using  Pure  Strategy 


E.  BALANCED  FORCE 

In  addition  to  providing  a  chain  of  command,  the  logistics  planner  is 
concerned  with  structuring  a  logistics  organization  with  balanced  capabilities. 
This  reflects  the  anticipated  need  to  have  the  capability  to  have  activities 
operating  independently  over  wide  areas  as  opposed  to  being  all  located  at  some 
central  area.  In  general,  battalions  with  the  same  mission  should  have  the  same 
capabilities.  This  is  often  difficult  to  achieve  because  the  unit  requirements 
estimated  above  may  not  partition  into  equivalent  battalions.  This  will  occur 
when  the  number  of  units  to  be  partitioned  is  not  a  multiple  of  the  number  of 
battalions  To  improve  force  balance,  it  may  be  desirable  to  adjust  unit 
requirements  in  order  to  achieve  a  better  partitioning  Because  of  the  levels  of 
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accuracy  in  the  methods  used  to  determine  force  requirements,  a  20  percent 
adjustment  factor  was  selected  as  the  acceptable  threshold  of  change  for  this 
thesis.  Therefore  if  15  supply  and  service  companies  were  to  be  distributed 
among  4  supply  battalions,  the  recommendation  of  15  would  be  changed  to  16  in 
order  to  allow  even  distribution  of  4  units  per  battalion.  It  should  also  be  noted 
the  balancing  is  done  by  individual  unit  type.  Two  battalions  must  have 
proportionate  amounts  of  the  same  type  of  units  in  order  to  be  considered 
balanced,  not  just  the  same  quantity  of  units. 
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III.  IMPLEMENTATION  AND  DESIGN 


A.  SYSTEMS  ORGANIZATION 

The  architecture  for  the  logistics  prototype  is  illustrated  in  Figure  3.1.  A 
brief  description  of  each  component  of  the  architecture  is  described  in  the 
paragraphs  below. 

The  collection  of  domain  knowledge  about  logistics  planning  is  contained  in 
the  knowledge  base.  For  the  prototype,  an  example  of  domain  knowledge  may  be 
a  particular  rule  used  to  determine  if  a  particular  logistics  unit  is  needed  to 
support  a  force. 
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The  inference  engine  contains  an  interpreter  that  decides  how  to  apply  the 
rules  of  the  knowledge  base  to  infer  new  knowledge.  In  addition,  the  inference 
engine  contains  a  scheduler  to  determine  the  order  in  which  rules  should  be 
applied.  [Ref.  2] 

The  user  interface  of  the  prototype  provides  two  major  functions.  First  it 
provides  the  user  a  means  of  updating  the  knowledge  base  with  force  dependent 
facts.  This  allows  the  prototype  to  tailor  the  logistics  force  to  a  specific  situation. 
Secondly,  the  user  interface  provides  the  results  of  using  the  prototype  by  way  of 
an  output  mechanism. 

B.  DATA  STRUCTURES 

The  list  and  the  tree  were  the  two  essential  data  structures  needed  to 
implement  the  prototype.  Since  the  prototype  was  implemented  in  the  PROLOG 
programming  language,  use  of  these  data  structures  was  quite  convenient  [Ref.  3], 

1.  Lists 

A  list  is  an  ordered  set  of  elements  of  finite  length.  An  element  of  a  list 
can  also  be  a  list.  The  first  element  of  a  list  is  the  "head”  and  the  remainder  of 
the  list  is  the  "tail".  The  examples  contained  in  Table  3.1  illustrate  the 
representation  of  lists  in  PROLOG. 

The  list  data  structure  is  provided  by  the  PROLOG  language  and  the 
language  allows  the  easy  manipulation  of  lists.  Any  list  can  be  represented  by 
[XjY]  where  X  is  the  head  of  the  list  and  Y  is  the  tail  of  the  list.  By  building 


TABLE  3.1  LIST  REPRESENTATION 


Prolog  List  Representation 

List 

Head 

Tail 

[a,b,c] 

a 

[b,c] 

[a,[b,c],d] 

a 

[[b,c],d] 

M 

a 

0 

fl 

no  head 

no  tail 

upon  this  representation  it  is  very  easy  to  develop  user  defined  list  processing 
functions  such  as  appending  an  item  to  a  list,  deleting  an  item  from  a  list  and 
numerous  others. 

2.  Trees 

A  tree  data  structure  can  be  easily  represented  by  using  the  list  data 
structure.  The  tree  data  structure  also  facilitates  representation  of  the  chain  of 
command  hierarchy  of  military  units.  In  the  prototype  there  was  a  need  to 
represent  a  three  level  tree.  The  root  of  the  tree  is  the  corps  support  command 
which  has  two  support  groups  as  its  children.  The  support  groups  have  various 
battalions  as  children.  Finally,  the  battalions  will  have  logistics  companies  as 
children.  The  companies  will  be  the  leaves  of  the  tree.  The  tree  diagram  in  Figure 
3.2  can  be  represented  by  the  following  list: 


[support_group,[supply_bns,maintenance_bns,petroleum_bns]] 


Supply- 

Battalions 


Maintenance 

Battalions 


Petroleum 

Battalions 


Figure  3.2  Tree  Structure  a  Support  Group 


Besides  being  an  excellent  representation  for  the  command  and  control 
hierarchy,  previously  defined  list  processing  functions  can  be  used  to  manipulate 
the  tree.  Therefore,  list  functions  can  manipulate  tree  data  structures. 

There  are  few  comments  regarding  the  tree  data  structure.  The  first 
point  is  that  the  level  of  nesting  of  lists  corresponds  to  the  level  of  the  tree.  The 
first  level  is  the  root  of  the  tree  and  the  last  level  of  nesting  represents  leaves  of 
the  tree.  For  the  purpose  of  the  prototype,  the  tree  is  a  multi-way  tree,  where  the 
number  of  children  for  any  tree  node  is  at  least  two  but  less  than  seven  [Ref.4], 
This  branching  factor  is  limited  because  of  the  real-world  constraint  that  limits  a 
unit  to  commanding  between  two  and  seven  units. 


C.  USER  INTERFACE 


The  user  interface  can  be  divided  into  the  input  and  the  output  requirements 
of  the  prototype.  Each  of  these  areas  is  discussed  below. 

1.  Input 

The  prototype  uses  a  menu-based  approach  to  obtain  user  information 
necessary  to  reach  conclusions  regarding  the  requirements  for  logistics  units. 
Menus  provide  an  easy  way  for  the  user  to  specify  the  composition  and  the 
mission  of  the  force. 

The  menus  used  in  the  prototype  were  implemented  by  an  "ask  which" 
predicate  written  by  Professor  Rowe  at  the  Naval  Postgraduate  School  [Ref  5]. 
The  "askwhich"  predicate  provides  the  user  with  a  set  of  questions  which  can  be 
answered  by  a  "yes"  or  a  "no".  The  user  is  then  asked  to  provide  the  numbers  to 
those  questions  which  can  be  answered  by  a  "yes".  The  "ask  which"  predicate 
then  asserts  facts  into  the  knowledge  base  on  the  basis  of  user  responses.  Table 
3.2  provides  a  sample  menu,  the  user  responses  and  the  resulting  facts  that  will  be 


added  to  the  knowledge  base. 


TABLE  3.2  USER  MENU 


Menu  for  User  Input 

1.  Are  "H"  series  armor  divisions  in  the  force? 

2.  Are  "J"  series  armor  divisions  in  the  force? 

3.  Are  "J"  series  mech  divisions  in  the  force? 

Give  numbers  of  questions  whose  answer  is  yes.  [1,2]. 

As  a  result  of  responding  that  questions  1  and  2  were  true, 
the  following  facts  were  added  to  the  knowledge  base: 

fact(armor_h_series). 
fact (armor  j  series). 

The  menu-based  approach  is  a  good  method  to  obtain  all  essential  facts 
that  are  relevant  to  any  planning  situation.  After  the  initial  information  is 
obtained,  the  prototype  will  only  ask  specific  questions  that  are  relevant  to  the 
user’s  previous  question  responses.  For  example,  if  a  user  specifies  that  armor 
divisions  are  in  the  force,  the  system  will  then  ask  the  user  how  many.  By  only 
asking  relevant  questions  in  view  of  previous  responses  the  system  is  able  to 
present  a  more  intelligent  interface  to  the  user.  The  interface  also  uses  "demons" 
to  activate  procedures  to  update  the  knowledge  base.  Demons  are  procedures  that 
are  only  activated  when  certain  conditions  are  satisfied.  For  example,  when  the 
user  specifies  the  force  will  be  deploying  to  a  cold  environment,  the  cold  weather 
condition  will  be  added  to  the  knowledge  base.  A  demon  can  recognize  the 
presence  of  this  condition  and  make  adjustments  to  the  logistics  consumption 
factors  that  will  be  increased  in  a  cold  environment  e.g.,  clothing  requirements. 


2.  Output 

The  primary  purpose  of  the  prototype’s  output  was  to  provide  the  user 
with  some  indication  as  to  why  specific  recommendations  regarding  force 
requirements  were  made.  For  example,  the  prototype  may  recommend  that  as  a 
minimum,  2  supply  and  service  units  are  needed  to  support  a  corps  force 
regardless  of  its  size  and  mission.  Finally,  the  prototype  displays  the  chain  of 
command  for  the  force  in  a  column  format.  All  companies  commanded  by  a 
particular  battalion  are  printed  in  a  column  that  is  shifted  to  the  right  of  the 
battalion.  Likewise,  all  battalions  are  printed  in  a  column  to  the  right  of  their 
commanding  support  group.  See  Appendices  A  and  B  if  additional  information 
on  output  formats  is  needed. 

D.  KNOWLEDGE  REPRESENTATION 

The  knowledge  associated  with  logistics  planning  was  represented  by  rules. 
Rules  were  selected  because  of  the  natural  way  in  which  they  represent  the  the 
knowledge  of  logistics  planners.  Besides  reflecting  the  way  that  many  experts 
solve  logistics  problems,  rules  are  easily  implemented  in  the  PROLOG  language 
used  for  the  prototype. 

Rules  have  the  format  of  "if  condition(s)  then  action(s)".  Table  3.3  provides 
some  typical  rules.  It  should  be  noted  that  some  conditions  can  in  fact  be  rules 
themselves.  For  example,  the  allocation  of  supply  and  service  units  is  based  upon 
the  type  of  scenario.  The  scenario  is  determined  by  a  scenario  rule.  Rules  like 


scenario  are  referred  to  as  intermediate  predicates.  Intermediate  predicates  allow 
the  generalization  of  several  facts  into  a  single  concept.  This  abstraction  greatly 
reduces  the  amount  of  conditions(or  rule  right  sides)  that  must  be  listed. 

The  PROLOG  representation  of  some  typical  rules  is  also  provided  in  Table 
3.3.  The  left  sides  of  PROLOG  rules  i.e.,  the  part  before  the  symbol  are  facts 
if  the  rule  right  sides  are  true. 

A  final  note  regarding  rules  concerns  rule  partitioning.  The  functional  nature 
of  logistics  units  allows  very  efficient  partitioning  of  the  knowledge  base.  For 
example,  rules  concerning  supply  units  can  be  written  into  a  file  while  rules  for 
maintenance  units  can  be  placed  into  another.  Partitioning  eases  development  by 
allowing  the  problem  to  be  decomposed  by  the  divide  and  conquer  strategy.  More 
importantly  however,  partitioning  can  support  more  efficient  implementation 
because  the  inference  engine  only  needs  the  rules  that  are  relevant  to  the  problem 
at  hand.  Thus  rules  concerning  maintenance  units  need  not  be  in  main  memory 
when  the  expert  system  is  determining  supply  unit  requirements. 

E.  INFERENCE  ENGINE 

A  backward-chaining-control  structure  was  chosen  for  the  inference  engine  of 
the  prototype.  With  backward  chaining  the  system  starts  with  some  goal  and 
tries  to  prove  it  by  use  of  the  rules  and  facts  contained  in  the  knowledge  base. 
The  selection  of  backward  chaining  was  based  upon  two  factors.  First  of  all.  the 
backward-chaining-control  structure  is  provided  by  the  PROLOG  interpreter  and 


TABLE  3.3  KNOWLEDGE  REPRESENTATION 


Knowledge  Representation  | 

Rales 

Prolog  Representation 

If  the  corps  is  s  heavy  corps  and 
the  expected  intensity  is  high 
then  planning  is  for  a  scenario 
of  the  first  type. 

scenario!  1)  :* 

fact  (heavy  corps), 
fact  (high  intensity) 

If  the  scenario  is  of  the  first  type  and 
the  number  of  divisions  is  known 
then  3  supply  and  service  companies 
are  required  per  division. 

unit(supply  and  Service  company, Required):- 
scenario(l), 
number  divisions(N), 

Required  is  N  *  3. 

If  the  scenario  is  of  the  first  type 
the  climate  is  not  cold 
then  5  lbs/ man  per  day  is  the 
planning  factor  for  miscellaneous 
equipment. 

factor(misc  equip, 5) 
scenario!  1), 
not(fact(cold)). 

thus  eliminated  the  development  of  another  control  structure.  Secondly, 
backward  chaining  appears  more  efficient  because  it  focuses  on  conclusions 
relevant  to  a  particular  planning  problem.  Backward  chaining  does  not  waste 
time  searching  for  information  unrelated  to  the  problem. 


F.  CONFLICT  RESOLUTION 

Chapter  II  discussed  the  fact  that  recommendations  concerning  a  unit  may 
conflict.  For  example,  one  rule  may  recommend  that  only  one  general  supply 
company  is  needed  while  another  rule  may  recommend  that  two  are  needed. 

Because  of  the  potential  for  conflicting  recommendations,  the  format  for  rules 
concerning  unit  requirements  is  as  follows: 


unit(Type  Unit, [Number  Recommended, Reason])  conditions. 


The  use  of  the  above  format  allows  the  prototype  to  collect  all 
recommendations  regarding  a  particular  unit  as  well  as  the  reason  for  the 
recommendations.  It  should  also  be  noted  that  when  the  above  rule  is  invoked, 
the  "Type  Unit"  and  "Reason"  are  bound  and  "Number  Recommended"  is 
unbound  until  the  rule  succeeds.  There  are  four  possible  types  of 
recommendations:  "minimum",  "general". "special"  and  "analogy'".  A  "minimum" 
type  recommends  a  minimum  number  of  required  units  regardless  of  mission 
characteristics.  A  "general"  makes  recommendations  based  upon  a  quantitative 
factor  e.g.,  one  unit  per  8000  soldiers  in  the  force.  A  "special"  makes 
recommendations  based  upon  the  special  characteristics  of  the  mission  provided 
by  the  user.  Finally,  an  "analogy"  recommends  a  required  number  by 
determining  the  number  required  in  an  existing  corps  force  with  a  similar  mission. 

The  reasons  types  discussed  above  are  used  to  assign  relative  weights  to  the 
recommendations  made  by  the  prototype.  Table  3.4  shows  an  example  of  some 
possible  recommendations  made  by  the  prototype.  The  sum  of  column  4  below  is 
divided  by  the  sum  of  column  3  in  order  to  obtain  a  weighted  average  for  the 
recommendations  i.e.,  2.  When  recommendations  are  made  that  fall  below  a 
"minimum"  recommendation,  they  are  eliminated  from  the  list  of 
recommendations.  The  conflict-resolution  strategy  also  performs  integer  division 
and  ignores  the  fractional  part  of  the  divison  in  order  to  determine  weighted 
averages.  A  more  liberal  approach  of  performing  division  and  rounding  to  the 
nearest  whole  integer  value  should  be  adopted  in  any  future  versions  of  the 


prototype.  Weighting  factors  are  similar  to  global  constants  in  traditional 
programming  languages  and  may  be  modified  quite  easily. 


G.  TREE  BUILDING  ALGORITHM 

The  previous  sections  identify  how  the  prototype  made  recommendations 
concerning  the  need  for  particular  logistics  units.  When  conflicting 
recommendations  are  made,  a  conflict  resolution  strategy  was  employed  to  reach  a 
final  conclusion.  This  section  concerns  the  arrangement  of  units  into  battalions 
and  support  groups  in  order  to  provide  a  chain  of  command  to  the  logistics  force. 

1.  Nature  of  Problem 

As  was  discussed  in  Chapter  II.  a  chain  of  command  must  be  provided  to 
the  logistics  units  that  ensures  the  optimal  arrangement  of  units  into  different 
groups  i.e..  battalions  and  support  groups.  Combinatorial  mathematics  is  the 
discipline  normally  associated  with  the  optima)  arrangement  of  objects  [Ref.  6], 

Unfortunately,  traditional  methods  of  combinatorial  mathematics  which 
guarantee  optimal  solutions  may  not  be  appropriate  to  the  present  problem  of 

TABLE  3.4  CONFLICT  RESOLUTION  STRATEGY 


Conflict  Resolution  Strategy 

,  Recommendation 

Reason 

Weight  Factor 

Weighted  Value 

1  I 

■ 

general 

• 

I 

1 

i  1 

minimum 

1 

1 

:  2 

analogy 

3 

6 

3 

special 

2 

6 

SUM 

7 

14 
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arranging  units  into  battalions  ard  support  groups.  This  is  due  to  the  fact  that 
enumeration  of  all  possible  solutions  to  the  problem  may  require  an  unacceptable 
amount  of  computing  time.  Furthermore,  it  may  be  impossible  to  specify  what 
exactly  an  optimum  arrangement  may  be  in  quantitative  terms.  In  view  of  these 
problems,  it  was  determined  that  a  heuristic  approach  providing  an  acceptable 
solution  to  the  problem  was  needed,  even  though  the  solution  may  not  guarantee 
an  optimal  solution. 

2.  Problem  Solution 

A  heuristic  approach  to  the  problem  was  chosen  that  uses  the  concept  of 
a  "greedy"  algorithm  to  reach  a  near  optimal  solution  Greedy  algorithms  ensure 
that  choices  made  at  each  step  of  a  solution  process  will  not  need  to  l>e  retracted 
at  a  later  steps  of  the  process  by  backtracking.  The  greedy  algorithm  is  more 
commonly  used  in  problems  such  as  transportation  networks  where  the  goal  is  to 
find  the  best  path  through  a  network  based  upon  some  criteria  eg.  maximum  or 
minimum  capacity  of  the  network. 

The  concept  of  the  greedy  algorithm  was  used  to  determine  an  acceptable 
solution  to  the  unit  arrangement  problem.  This  was  possible  l**cause  the  chain  of 
command  structure  requires  the  piecemeal  building  of  a  hierarchical 
organizational  structure  or  tree  diagram  from  the  bottom- up  Companies  must  lie 
assigned  to  battalions  before  battalions  can  be  assigned  to  support  groups  At 
each  step  of  this  tree  building  process,  the  best  assignment  of  units  is  made 

locally.  For  example,  the  best  assignment  of  units  is  made  to  make  balanced 
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battalions  without  regard  to  balancing  support  groups.  Once  battalions  have  been 
developed,  the  best  assignment  of  battalions  is  made  to  balance  the  capabilities 
between  two  support  groups. 

The  formal  representation  of  the  tree  building  algorithm  is  discussed  in 
Figure  3.3.  The  terminology  of  "children"  and  "parent"  used  when  discussing 
tree  data  structures  is  analagous  to  the  command  relationship  that  exists  between 
rompanies(rhildren)  and  battalions( parents).  Likewise,  battalions  are  children  to 
the  support  groups. 

The  tree  building  algorithm  is  general  enough  that  it  can  be  used  to 
allocate  units  to  battalions  and  battalions  to  support  groups  To  better 
understand  the  allocation  process.  Table  3.5  shows  4  supply  and  service 
companies.  2  general  supply  companies  and  1  repair  parts  company  being 
allocated  to  2  supply  battalions.  The  algorithm  also  ensures  that  a  height- 
balanced-multi-way  tree  is  produced  Ref  4: 

The  chain  of  command  strategies  of  "mixed"  and  "pure"  discussed  in 
Chapter  II  are  easily  implemented  by  the  prototype  using  the  same  tree  building 
algorithm.  The  only  difference  between  the  two  strategies  concerns  the  initial 
step  of  collecting  units  to  be  distributed  to  parents.  The  "mixed"  strategy  collects 
units  by  functional  specification  only  e  g  ,  supply  while  the  "pure"  strategy 
collects  units  to  be  distributed  by  functional  specification  and  capability  e  g  . 
supply  and  direct  support 
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Create  a  list  of  candidate  children,  segregated  by  type,  that  can  be  assigned 
to  the  same  type  parents.  For  example,  supply  units  can  be  assigned  to 
supply  battalions.  All  company  sized  units  must  be  assigned  to  battalions 
before  battalions  can  be  assigned  to  support  groups. 

Determine  the  number  of  parents  needed  to  allocate  the  list  of  children 
identified  in  "1"  above.  Then  create  an  ordered  list  of  "N"  parents  that  the 
list  of  children  identified  in  "1"  above  can  be  allocated  to.  e.g., 
[[supply  battalionl], [supply  battalion2j... [supply  battalionX]]. 

Remove  the  first  element  of  the  children  list  and  assign  it  to  a  parent  as 
follows: 

a.  If  all  parents  have  an  equal  number  of  children  then  assign  to  to 
the  first  parent  in  the  parent  list. 

b.  If  all  parents  are  not  equal  then  assign  to  the  first  parent  that  has 
one  less  than  its  immediate  predecessor. 


Repeat  step  "3"  until  the  children  list  is  exhausted. 

Repeat  step  "I"  untal  all  children  i.e..  supply. maintenance  and  petroleum 
companies  have  been  assigned  parents.  The  last  iteration  should  be  the 
assignment  of  the  battalions  that  have  been  created  to  two  support 
groups. 


Figure  3.3  Tree  Building  Algorithm 


TABLE  3.5  TREE  BUILDING  ALGORITHM  EXAMPLE 


Tree  Building  Algorithm  Example 

Step 

Supply  Battalion  1 

Supply  Battalion  2 

Step  1 

no  units 

no  units 

Step  2 

supply  ii  service  company 

Step  3 

supply  ic  service  company 

supply  &  service  company 

Step  4 

supply  A  service  company 
supply  ii  service  company 

supply  &  service  company 

Step  5 

supply  A  service  company 
supply  A  service  company 

supply  &  service  company 
supply  &  service  company 

Step  6 

supply  A  service  company 
supply  L  service  company 
supply  4:  service  company 

supply  L  service  company 
supply  L  service  company 

Step  7 

supply  A  service  company 
supply  A  service  company 
supply  L  service  company 

supply  &c  service  company 
supply  ii  service  company 
general  supply  company 

Step  8 

supply  L  service  company 
supply  L  service  company 
supply  L  service  company 
general  supply  company 

supply  A  service  company 
supply  ii  sendee  company 
general  supply  company 

Step  9 

supply  t  service  company 
supply  L  service  company 
supply  A  service  company 
general  supply  company 

supply  A  sendee  company 
supply  &  service  company 
general  supply  company 
repair  parts  company 

H.  TREE  BALANCING 

The  final  task  of  the  prototype  was  to  make  adjustments  to  the  initial 
recommendations  so  a  more  balanced  force  structure  or  tree  could  he  developed. 
This  was  accomplished  by  adjusting  initial  recommendations  for  each  type  of  unit 
so  that  the  adjusted  number  represented  a  multiple  of  the  number  of  battalions  to 
which  they  would  be  assigned.  This  is  done  only  when  the  adjustment  is  less  than 
plus  or  minus  20  percent  of  the  original  recommendation  provided  by  the 


prototype.  For  example,  if  16  supply  and  service  units  are  to  be  assigned  to  3 


supply  battalions,  the  number  of  supply  and  service  units  would  be  adjusted  to 
15.  Besides  the  20  percent  constraint,  the  adjustment  was  made  by  selecting  the 
closest  multiple  regardless  of  whether  it  was  an  increase  or  decrease.  Using  the 
previous  example,  the  numbers  18  and  12  are  also  multiples  of  three  but  15  is  the 
closest  multiple. 
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IV.  RESULTS 


A.  SYSTEM  REQUIREMENTS 

The  prototype  was  implemented  on  a  Digital  Equipment  Corporation  VAX 
11/785  minicomputer  running  the  UNIX  operating  system.  The  prototype  was 
written  using  a  C-Prolog  interpreter  developed  at  the  University  of  Edinburgh 
[Ref.  3]. 

B.  SYSTEM  STATISTICS 

The  prototype  occupies  a  maximum  of  35. 5K  bytes  of  memory.  Table  4.1 
provides  some  run  time  statistics  on  two  test  cases  that  were  using  the  prototype. 
The  output  listing  for  both  test  cases  are  contained  in  Appendices  A  and  B. 

C.  TEST  1:  HEAVY  CORPS 

Appendix  A  contains  the  results  of  running  the  prototype  to  determine  the 
logistical  units  needed  to  support  a  6  division  force  consisting  of  heavy  armor  and 
mechanized  units.  As  should  be  expected  the  force  requires  significant  logistical 
support  i.e.,  54  units. 
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TABLE  4.1  RUN  TIME  RESULTS 


Test 


System  Run  Time  Results 


Connect-Time  CPU-Time  Global  Stack 
Seconds  Seconds  K-bytes 


70  36.18  62 

55  20.85  25 


Local  Stack 
K-bytes 


54 

29 


D.  TEST  2:  LIGHT  CORPS 

Appendix  B  contains  the  results  of  running  the  prototype  to  determine  the 
logistical  units  needed  to  support  a  3  division  force  consisting  of  light  airborne 
and  infantry  divisions.  As  should  be  expected  the  logistics  force  is  considerably 
smaller  than  the  previous  one  i.e.,  27  units  versus  54. 


V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

The  adoption  of  an  expert  systems  approach  to  the  domain  of  logistics 
planning  appears  to  be  technically  feasible.  In  particular,  an  expert  systems 
approach  appears  to  be  an  excellent  way  to  resolve  logistics  planning  since  it  relies 
so  heavily  upon  heuristics.  The  PROLOG  language  was  an  excellent  tool  to 
develop  the  prototype. 

The  translation  of  logistics  rules  or  heuristics  into  encoded  PROLOG  rules 
was  easily  accomplished.  Any  serious  implementation  of  an  expert  logistics 
planning  system  would  require  a  substantial  increase  in  knowledge  engineering  to 
meaningfully  capture  the  entire  complexity  of  the  problem.  Once  the  knowledge 
engineering  task  is  adequately  performed  however,  the  task  of  enhancing  the 
knowledge  base  can  accomplished  and  the  resulting  performance  of  the  system 
improved  markedly. 

Although  other  control  structures  exists,  the  backward-chaining-control 
structure  appears  to  best  suited  to  the  task  because  it  focuses  on  relevant 
conclusions  needed  to  determine  solutions.  This  could  also  be  a  benefit  to  future 
implementations  since  backward  chaining  is  provided  in  the  PROLOG  language 
and  also  in  most  expert  systems  shells  currently  available. 


The  problem  of  arranging  logistics  unite  into  a  structured  force  i.e.,  battalions 
and  groups,  proved  to  be  one  of  the  most  interesting  problems  of  the  thesis.  This 
thesis  presents  one  method  to  solve  the  problem.  The  solution  technique 
highlights  one  of  the  most  important  aspects  of  expert  systems:  the  ability  to 
resolve  problems  by  rules  or  heuristics  when  more  traditional  algorithmic  solutions 
are  not  feasible  or  practical.  Good  heuristic  solutions  to  allocation  problems  could 
be  used  in  numerous  application  areas. 

The  functional  nature  of  logistics  e.g.,  supply,  maintenance,  etc.  suggests  that 
a  full  implementation  of  a  logistics  planning  system  could  be  developed  to  work  in 
a  parallel  processing  environment.  For  example,  one  processor  could  be  working 
on  supply  units  while  another  is  working  on  maintenance  units  to  develop  the 
required  supply  and  maintenance  battalions  needed  by  the  force.  The  resulting 
battalions  could  then  be  allocated  to  the  support  groups  by  another  processor.  i 

This  ability  could  significantly  increase  performance  of  the  system  and  reduce  any 
criticism  about  the  slowness  of  expert  systems. 

A  full  development  of  the  system  could  provide  extensive  explanation 
facilities  to  increase  the  interaction  between  users  and  the  system.  A  human 
expert  could  then  override  the  system  when  recommendations  and  corresponding  . 

explanations  do  not  appear  to  be  plausible.  The  system  could  also  be  developed 
for  Computer-Aided  Instruction  so  students  could  gain  instant  feedback  on  the  j 

relationships  between  the  combat  force  and  the  logistics  force. 

i 
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Perhaps  the  biggest  weakness  of  the  prototype  is  possible  resistance  of  users  to 
accept  and  use  the  system.  Skeptics  will  be  quick  to  point  to  its  weaknesses  and 
its  shortfalls.  This  situation  should  not  preclude  adopting  the  system,  but  it  does 
emphasize  the  need  for  good  knowledge  engineering  to  ensure  that  the  system 
adequately  represents  the  knowledge  possessed  by  experts.  It  should  also  be 
recognized  that  the  system  will,  like  most  human  experts,  make  mistakes.  Making 
mistakes  is  not  a  reason  for  abandoning  the  system,  but  an  opportunity  to 
improve  the  system  by  giving  it  additional  knowledge  to  preclude  repetition  of  the 
error.  Despite  these  possible  problems,  an  expert  system(if  properly  implemented) 
can  perform  the  tasks  of  experts  in  a  rigorous  way  on  a  daily  basis. 

B.  RECOMMENDATIONS 

It  is  recommended  that  an  enhanced  prototype  be  developed.  During 
development,  extensive  effort  should  be  made  to  capture  expert  knowledge  from 
domain  experts.  The  enhanced  prototype  should  then  be  tested  against  the 
experts  to  determine  its  performance  and  practicality. 

It  is  also  recommended  that  additional  research  be  performed  to  determine 
the  applicability  of  rule-based  methods  of  determining  solutions  to  allocation 
problems.  In  particular  allocation  or  arrangement  of  objects  into  a  balance  tree 


structure  should  be  pursued. 


APPENDIX  A 


TEST  1:  HEAVY  CORPS 

%  prolog 

I: Are  "J"  series  armor  divisions  in  the  force? 

2: Are  "H"  series  armor  divisions  in  the  force? 

3:Are  "J"  series  mech  divisions  in  the  force? 

4:Are  "H"  series  mech  divisions  in  the  force? 

5:Are  airborne  divisions  in  the  force? 

6:Are  air  assault  divisions  in  the  force? 

7: Are  motorized  divisions  in  the  force? 

8:Are  light  infantry  divisions  in  the  force? 

9:Are  standard  infantry  divisions  in  the  force? 

Give  number  of  only  question  whose  answer  is  yes.  [1,2.3], 

Please  enter  the  number  of  "J"  series  armor  divisions?l. 

Please  enter  the  number  of  "H"  series  armor  divisions?2. 

Please  enter  the  number  of  "J"  series  mech  divisions?3. 

1:1s  the  force  to  be  engaged  in  a  low  intensity  conflict? 

2:1s  the  force  to  be  engaged  in  a  mid  intensity  conflict? 

3: Is  the  force  to  be  engaged  in  a  hi  intensity  conflict? 

Give  number  of  only  question  whose  answer  is  yes.  [3]. 

1:1s  the  force  to  be  depoloyed  to  a  cold  environment? 

2:1s  the  force  to  be  deployed  to  a  temperate  climate? 

3:1s  the  force  to  be  deployed  to  a  hot  environment? 

Give  number  of  only  question  whose  answer  is  yes. [l] . 

The  daily  force  requirement  for  rations  is:  212  short  tons 
The  daily  force  requirement  for  misc  equip  is:  318  short  tons 
The  daily  force  requirement  for  petroleum  is:  2862  short  tons 
The  daily  force  requirement  for  ammo  is:  1855  short  tons 
The  daily  force  requirement  for  barrier  materiel  is:  424  short  tons 
The  daily  force  requirement  for  personnel  items  is:  159  short  tons 
The  daily  force  requirement  for  major  items  is:  954  short  tons 
The  daily  force  requirement  for  medical  items  is:  106  short  tons 


REQUIREMENTS  ANALYSIS  FOR:  heavy-materiel  company 
INITIAL  RECOMMENDATIONS: 

[l. general] 

[1,  minimum] 

[2. analogy] 

[2.special] 

REVISED  LIST: 

[l, general] 

[1.  minimum] 

[2. analogy] 

[2.special] 

FINAL  RECOMMENDATION: 

1 

REQUIREMENTS  ANALYSIS  FOR:  supply-and  service  company 
INITIAL  RECOMMENDATIONS: 

[4  .general] 

[6  .minimum] 

[16. analogy] 

[18, special] 

REVISED  LIST: 

[6. minimum] 

[l6.analogy] 

[18. special] 

FINAL  RECOMMENDATION: 

15 


REQUIREMENTS  ANALYSIS  FOR:  general-supply  company 


INITIAL  RECOMMENDATIONS: 
[2,general] 


[2. minimum 


[3.general] 

[6  .special] 
[8.analogy] 
REVISED  LIST: 


[2.general] 


12.  minimum 


[3.general] 

[6.special] 

[8. analogy] 

FINAL  RECOMMENDATION: 
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REQUIREMENTS  ANALYSIS  FOR:  repair-parts  supply  company 

INITIAL  RECOMMENDATIONS: 

[l. analogy] 

[l.  minimumj 
[3,general] 

REVISED  LIST: 

[l,  analogy] 

[l.minimum] 

[3.general] 

FINAL  RECOMMENDATION: 

1 

REQUIREMENTS  ANALYSIS  FOR:  maintenance-company  dsfwd 
INITIAL  RECOMMENDATIONS: 

[4. minimum] 

[I2.special] 

REVISED  LIST: 

[4. minimum] 

[I2.special] 

FINAL  RECOMMENDATION: 

9 

REQUIREMENTS  ANALYSIS  FOR:  maintenance  companv-dsrear 
INITIAL  RECOMMENDATIONS: 

[2. minimum] 

[6.special] 

REVISED  LIST: 

[2.minimum] 

]6.special] 

FINAL  RECOMMENDATION: 

4 

REQUIREMENTS  ANALYSIS  FOR:  light-maintenance  company  gs 
INITIAL  RECOMMENDATIONS: 

[4. minimum] 

[l2.special] 

REVISED  LIST: 

[4. minimum] 

[  12  .special] 

FINAL  RECOMMENDATION: 

9 


REQUIREMENTS  ANALYSIS  FOR:  petroleum-supply  company 
INITIAL  RECOMMENDATIONS: 

[©.minimum] 

[13, general] 

REVISED  LIST: 

[©.minimum] 

[13, general] 

FINAL  RECOMMENDATION: 

9 

REQUIREMENTS  ANALYSIS  FOR:  medium-truck  company 
INITIAL  RECOMMENDATIONS: 

[2,analogy] 

[2,general] 

[2.minimum] 

REVISED  LIST: 

[2.analogy] 

[2,general] 

[2. minimum] 

FINAL  RECOMMENDATION: 

2 


COMMAND  AND  CONTROL  STRUCTURE  USING  MIXED  ALGORITHM: 


1st  SPT  GRP 

1st  SUPPLY  BN 

1st  supplv-and  service  company 
2nd  supply-and  service  company 
3rd  supply-and  service  company 
4th  repair-parts  supply  company 
5th  general-supply  company 
2nd  SUPPLY  BN 

1st  supply-and  service  company 
2nd  supply-and  service  company 
3rd  supply-and  service  company 
4th  supply-and  service  company 
oth  general-supplycompanv 
6th  general-supply  company 
1st  MAINT  BN 

1st  maintenance  company-dsrear 
2nd  maintenance-company  dsfwd 
3rd  maintenance-company  dsfwd 
4th  light-maintenance  company  gs 
5th  light-maintenance  company  gs 
2nd  MAINT  BN 

1st  maintenance  company-dsrear 
2nd  maintenance-company  dsfwd 
3rd  maintenance-company  dsfwd 
4th  light-maintenance  company  gs 
5th  light-maintenance  company  gs 
6th  light-maintenance  company  gs 
1st  PETROL  BN 

1st  petroleum-supply  company 
2nd  petroleum-supply  company 
3rd  petroleum-supply  company 
4th  petroleum-supply  company 
5th  petroleum-supply  company 
6th  medium-truck  company 


I 
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2nd  SPT  GRP 

1st  SUPPLY  BN 

1st  supply-and  service  company 
2nd  supply-and  service  company 
3rd  supply-and  service  company 
4th  supply-and  service  company 
5th  general-supplv  companv 
2nd  SUPPLY  BN 

1st  supply-and  service  company 
2nd  supply-and  service  company 
3rd  supply-and  service  company 
4th  supply-and  service  company 
5th  heavy-materiel  company 
6th  general-supply  company 
1st  MAINT  BN 

1st  maintenance  company-dsrear 
2nd  maintenance-company  dsfwd 
3rd  maintenance-company  dsfwd 
4th  light-maintenance  company  gs 
5th  light-maintenance  company  g> 
2nd  MAINT  BN 

1st  maintenance  company-dsrear 
2nd  maintenance-company  dsfwd 
3rd  maintenance-company  dsfwd 
4th  maintenance-company  dsfwd 
5th  light-maintenance  company  gs 
6th  light-maintenance  company  gs 
1st  PETROL  BN 

1st  petroleum-supply  company 
2nd  petroleum-supply  company 
3rd  petroleum-supply  company 
4th  petroleum-supply  company 
5th  medium-truck  company 


THE  FOLLOWING  REC  OMMENDATIONS  WERE  MADE  TO  BALANCE  THE  FORCE 
The  old  number  for  supply-and  service  company  was  changed  from  15  to  16  . 

The  old  number  for  general-supply  company  was  changed  from  5  to  4 
The  old  number  for  maintenance-company  dsfwd  was  changed  from  9  to  8  . 

The  old  number  for  light-maintenance  company  gs  was  changed  from  9  to  8 
The  old  number  for  petroleum-supply  company  was  changed  from  9  to  10  . 

COMMAND  AND  CONTROL  STRUCTURE  USING  MIXED  ALGORITHM 
AFTER  BALANCING: 

1st  SPT  GRP 

1st  SUPPLY  BN 

1st  supply-and  service  company 
2nd  supply-and  service  company 
3rd  supply-and  service  company 
4th  supply-and  service  company 
oth  gpneral-supply  company 
2nd  SUPPLY  BN 

1st  supply-and  service  company 
2nd  supply-and  service  company 
3rd  supply-and  service  company 
4th  supply-and  service  company 
5th  heavy-materiel  company 
6th  general-supply  company 
1st  M AIN'T  BN 

1st  maintenance  companv-dsrear 
2nd  maintenance-company  dsfwd 
3rd  maintenance-company  dsfwd 
4th  light-maintenance  company  gs 
5th  light-maintenance  company  gs 
2nd  M AIN'T  BN 

1st  maintenance  companv-dsrear 
2nd  maintenance-company  dsfwd 
3rd  maintenance-company  dsfwd 
4th  light-maintenance  company  gs 
5th  light-maintenance  company  gs 
1st  PETROL  BN 

1st  petroleum-supply  company 
2nd  petroleum-supply  company 
3rd  petroleum-supply  company 
4th  petroleum-supply  company 
5th  petroleum-supply  company 
6th  medium-truck  company 


2nd  SPT  GRP 

1st  SUPPLY  BN 

1st  supply-and  service  company 
2nd  supply-and  service  company 
3rd  supply-and  service  company 
4th  supply-and  service  company 
5th  general-supply  company 
2nd  SUPPLY  BN 

1st  supply-and  service  company 
2nd  supply-and  service  company 
3rd  supply-and  service  company 
4th  supply-and  service  company 
5th  repair-parts  supply  company 
6th  general-supply  company 
1st  MAINT  BN 

1st  maintenance  company-dsrear 
2nd  maintenance-company  dsfwd 
3rd  maintenance-company  dsfwd 
4th  light- maintenance  company  gs 
5th  light-maintenance  company  gs 
2nd  MAINT  BN 

1st  maintenance  company-dsrear 
2nd  maintenance-company  dsfwd 
3rd  maintenance-company  dsfwd 
4th  light-maintenance  company  gs 
5th  light-maintenance  company  gs 
1st  PETROL  BN 

1st  petroleum-supply  company 
2nd  petroleum-supply  company 
3rd  petroleum-supply  company 
4th  petroleum-supply  company 
5th  petroleum-supply  company 
6th  medium-truck  company 


COMMAND  AND  CONTROL  STRUCTURE  USING  PURE  ALGORITHM: 


1st  SPT  GRP 

1st  MAINT  BN 

1st  light-maintenance  company  gs 
2nd  light-maintenance  company  gs 
3rd  light-maintenance  company  gs 
4th  light-maintenance  company  gs 
2nd  MAINT  BN 

1st  maintenance  company-dsrear 
2nd  maintenance  company-dsrear 
3rd  maintenance-company  dsfwd 
4th  maintenance-company  dsfwd 
5th  maintenance-company  dsfwd 
6th  maintenance-company  dsfwd 
1st  SUPPLY  BN 

1st  supply-and  service  company 
2nd  supply-and  service  company 
3rd  supply-and  service  company 
4th  supply-and  service  company 
5th  supply-and  service  company 
2nd  SUPPLY  BN  “ 

1st  repair-parts  supply  company 
2nd  heavv-materiel  company 
3rd  general-supply  company 
4th  general-supply  company 
5th  general-supply  company 
6th  general-supply  company 
1st  PETROL  BN 

1st  petroleum-supply  company 
2nd  petroleum-supply  company 
3rd  petroleum-supply  company 
4th  petroleum-supply  company 
5th  petroleum-supply  company 
6th  medium-truck  company 
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2nd  SPT  GRP 

1st  MAINT  BN 

1st  light-maintenance  company  gs 
2nd  light-maintenance  company  gs 
3rd  light-maintenance  company  gs 
4th  light-maintenance  company  gs 
2nd  MAINT  BN 

1st  maintenance  company-dsrear 
2nd  maintenance  company-dsrear 
3rd  maintenance-company  dsfwd 
4th  maintenance-company  dsfwd 
5th  maintenance-company  dsfwd 
6th  maintenance-company  dsfwd 
1st  SUPPLY  BN 

1st  supply-and  service  company 
2nd  supply-and  service  company 
3rd  supply-and  service  company 
4th  supply-and  service  company 
5th  supply-and  service  company 
2nd  SUPPLY  BN 

1st  supply-and  service  company 
2nd  supply-and  service  company 
3rd  supply-and  service  company 
4th  supply-and  service  company 
5th  supply-and  service  company 
6th  supply-and  service  company 
1st  PETROL  BN 

1st  petroleum-supply  company 
2nd  petroleum-supply  company 
3rd  petr^leum-supplv  company 
4th  petroleum-supply  company 
5th  petroleum-supply  company 
6th  medium-truck  company 

[  Prolog  execution  halted  ] 
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APPENDIX  B 


TEST  2:  LIGHT  CORPS 

%  prolog 

l:Are  "J"  series  armor  divisions  in  the  force? 

2: Are  "H"  series  armor  divisions  in  the  force? 

3:Are  "J”  series  mech  divisions  in  the  force? 

4:Are  "H"  series  mech  divisions  in  the  force? 

5:Are  airborne  divisions  in  the  force? 

6:Are  air  assault  divisions  in  the  force? 

7: Are  motorized  divisions  in  the  force? 

8:  Are  light  infantry  divisions  in  the  force? 

9:Are  standard  infantry  divisions  in  the  force? 

Give  number  of  only  question  whose  answer  is  yes. [5.9]. 

Please  enter  the  number  of  airborne  divisions?!. 

Please  enter  the  number  of  standard  infantry  divisions?2. 

1:1s  the  force  to  be  engaged  in  a  low  intensity  conflict? 

2:1s  the  force  to  be  engaged  in  a  mid  intensity  conflict? 

3:1s  the  force  to  be  engaged  in  a  hi  intensity  conflict? 

Give  number  of  only  question  whose  answer  is  yes. [3]. 

'M 

1:1s  the  force  to  be  depoloved  to  a  cold  environment? 

2 :Is  the  force  to  be  deployed  to  a  temperate  climate? 

3: Is  the  force  to  be  deployed  to  a  hot  environment? 

Give  number  of  only  question  whose  answer  is  yes.  [2]. 

‘M 

The  daily  force  requirement  for  rations  is:  98  short  tons 
The  daily  force  requirement  for  misc  equip  is:  122  short  tons 
The  daily  force  requirement  for  petroleum  is:  1151  short  tons 
The  daily  force  requirement  for  ammo  is:  612  short  tons 
The  daily  force  requirement  for  barrier  materiel  is:  196  short  tons 
The  daily  force  requirement  for  personnel  items  is:  73  short  tons 
The  daily  force  requirement  for  major  items  is:  367  short  tons 
The  daily  force  requirement  for  medical  items  is:  24  short  ions 
\\1 
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REQUIREMENTS  ANALYSIS  FOR:  heavy-materielcompany 
INITIAL  RECOMMENDATIONS: 

[1. analogy] 

[1, general] 

[1. minimum] 

[l.speciai] 

REVISED  LIST: 

[1. analogy] 

[1, general] 

[l.  minimum] 

[l.speciai] 

FINAL  RECOMMENDATION: 

1 

REQUIREMENTS  ANALYSIS  FOR:  supply-and  service  company 
INITIAL  RECOMMENDATIONS: 

[l. minimum] 

[2, general] 

[6,special] 

[8. analogy] 

REVISED  LIST: 

[1. minimum] 

[2.general] 

[6.special] 

[8.  analogy] 

FINAL  RECOMMENDATION: 

5 

REQUIREMENTS  ANALYSIS  FOR:  general-supply  company 
INITIAL  RECOMMENDATIONS: 

[l, general] 

[1. minimum] 

[l.speciai] 

[4. analogy] 

REVISED  LIST: 

[1. general] 

[l. minimum] 

[l.speciai] 

[4. analogy] 

FINAL  RECOMMENDATION: 

2 

REQUIREMENTS  ANALYSIS  FOR:  repair-parts  supply  company 
INITIAL  RECOMMENDATIONS: 
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[1. analogy] 

[l. minimum] 

[3,general] 

REVISED  LIST: 

[l. analogy] 

[l, minimum] 

(3  .general] 

FINAL  RECOMMENDATION: 

1 

REQUIREMENTS  ANALYSIS  FOR:  maintenance-company  dsfwd 
INITIAL  RECOMMENDATIONS: 

[3,special] 

[4,minimum] 

[10, analogy] 

REVISED  LIST: 

[4. minimum] 

[10. analogy] 

FINAL  RECOMMENDATION: 

8 

REQUIREMENTS  ANALYSIS  FOR:  maintenance  company-dsrear 
INITIAL  RECOMMENDATIONS: 

[  1  .special] 

[2. minimum] 

[5. analogy] 

REVISED  LIST: 

[2. minimum] 

[5. analogy] 

FINAL  RECOMMENDATION: 

4 

REQUIREMENTS  ANALYSIS  FOR:  light-maintenance  company  gs 
INITIAL  RECOMMENDATIONS: 

[2. minimum] 

[S.special] 

REVISED  LIST: 

[2. minimum] 

[S.special] 

FINAL  RECOMMENDATION: 

2 


REQUIREMENTS  ANALYSIS  FOR:  petroleum-supply  company 


INITIAL  RECOMMENDATIONS: 

[I. minimum] 

[5.general] 

REVISED  LIST: 

[l.minimum] 

[5. general] 

FINAL  RECOMMENDATION: 

3 

REQUIREMENTS  ANALYSIS  FOR:  medium-truck  company 
INITIAL  RECOMMENDATIONS: 

[1, general] 

[l.minimum] 

[2. analogy] 

REVISED  LIST: 

[l, general] 

[l.minimum] 

[2. analogy] 

FINAL  RECOMMENDATION: 

1 
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COMMAND  AND  CONTROL  STRUCTURE  USING  MIXED  ALGORITHM 


1st  f'T  T  GRP 

1st  SUPPLY  BN 

1st  supply-and  service  company 
2nd  supply-andservice  company 
3rd  supply-and  service  company 
4th  heavy-materielcompany 
5th  general-supply  company 
1st  MAINT  BN 

1st  maintenancecompany-dsrear 
2nd  maintenance  company-dsrear 
3rd  maintenance-company  dsfwd 
4th  maintenance-company  dsfwd 
5th  light-maintenance  company  gs 
1st  PETROL  BN 

1st  petroleum-supply  company 
2nd  petroleum-supply  company 
3rd  petroleum-supply  company 
4th  medium-truck  company 

2nd  SPT  GRP 

1st  SUPPLY  BN 

1st  supply-and  service  company 
2nd  supplv-and  service  company 
3rd  repair-parts  supply  company 
4th  general-supply  company 
1st  MAINT  BN 

1st  maintenance  company-dsrear 
2nd  maintenance-company  dsfwd 
3rd  maintenance-company  dsfwd 
4th  maintenance-company  dsfwd 
2nd  MAINT  BN 

1st  maintenance  company-dsrear 
2nd  maintenance-company  dsfwd 
3rd  maintenance-company  dsfwd 
4th  maintenance-company  dsfwd 
5th  light-maintenance  company  gs 


THE  FOLLOWING  RECOMMENDATIONS  WERE  MADE  TO  BALANCE  THE  FORCE: 
The  old  number  for  supply-and  service  company  was  changed  from  5  to  6  . 

The  old  number  for  maintenance-company  dsfwd  was  changed  from  8  to  9  . 

The  old  number  for  maintenance  company-dsrear  was  changed  from  4  to  3  . 

COMMAND  AND  CONTROL  STRUCTURE  USING  MIXED  ALGORITHM 
AFTER  BALANCING: 

1st  SPT  GRP 

1st  SUPPLY  BN 

1st  supply-andservice  company 
2nd  supply-and  service  company 
3rd  supply-and  service  company 
4th  heavy-materiel  company 
5th  general-supply  company 
1st  MAINT  BN 

1st  maintenance  company-dsrear 
2nd  maintenance-company  dsfwd 
3rd  maintenance-company  dsfwd 
4th  maintenance-company  dsfwd 
oth  light-maintenance  company  gs 
1st  PETROL  BN 

1st  petroleum-supply  company 
2nd  petroleum-supply  company 
3rd  petroleum-supply  company 
4th  medium-truck  company 

2nd  SPT  GRP 

1st  SUPPLY  BN 

1st  supply-and  service  company 
2nd  supply-and  service  company 
3rd  supply-and  service  company 
4th  repair-parts  supply  company 
5th  general-supply  company 
1st  MAINT  BN 

1st  maintenance  company-dsrear 
2nd  maintenance-company  dsfwd 
3rd  maintenance-company  dsfwd 
4th  maintenance-company  dsfwd 
2nd  MAINT  BN 

1st  maintenancecompany-dsrear 
2nd  maintenance-company  dsfwd 
3rd  maintenance-company  dsfwd 
4th  maintenance-company  dsfwd 
5th  light-maintenance  company  gs 


COMMAND  AND  CONTROL  STRUCTURE  USING  PURE  ALGORITHM 


1st  SPT  GRP 

1st  MAINT  BN 

1st  maintenance  company-dsrear 
2nd  maintenance  company-dsrear 
3rd  maintenance-company  dsfwd 
4th  maintenance-company  dsfwd 
5th  maintenance-company  dsfwd 
6th  maintenance-company  dsfwd 
1st  SUPPLY  BN 

1st  supply-and  service  company 
2nd  supply-and  service  company 
3rd  supply-and  service  company 
4th  supply-and  service  company 
5th  supply-and  service  company 
6th  supply-and  service  company 
1st  PETROL  BN 

1st  petroleum-supply  company 
2nd  petroleum-supply  company 
3rd  petroleum-supply  company 
4th  medium-truck  company 

2nd  SPT  GRP 

1st  MAINT  BN 

1st  light-maintenance  company  gs 
2nd  light-maintenance  company  gs 
2nd  MAINT  BN 

1st  maintenance  company-dsrear 
2nd  maintenance-company  dsfwd 
3rd  maintenance-company  dsfwd 
4th  maintenance-company  dsfwd 
5th  maintenance-company  dsfwd 
6th  maintenance-company  dsfwd 
1st  SUPPLY  BN 

1st  repair-parts  supply  company 
2nd  heavy-materiel  company 
3rd  general-supply  company 
4th  general-supply  company 
[  Prolog  execution  halted  ] 


APPENDIX  C 


SOURCE  CODE 

/*The  "logistic  force"  predicate  is  the  top  level  predicate  used  by  the  logistics 
planning  system.  The  first  call  is  to  load  the  system  via  the  "load  system" 
predicate.  After  all  necessary  files  have  been  loaded  the  user  is  queried  for  the 
composition  of  force  via  the  "forcelist"  predicate.  Next  the  user  is  asked  for 
information  about  unique  mission  characteristics  via  the  "environmental  factors" 
predicate.  Finally,  after  all  necessary  input  data  has  been  provided  to  the  system, 
a  series  of  calls  "requirements"  is  made  to  determine  the  actual  type  and 
quantitity  of  logistic  units  that  are  needed.  Command  and  control  of  selected 
units  is  determined  by  the  "tree"  predicate.*/ 

logistic  force  :- 

prog([load  system, 
force  list. 

environmental  factors. 
doall(calculate). 

requirements(heavy-materiel  company  .supply  ,gs). 
requirements  (supply-and  sendee  company  .supply  .ds). 
requirements  (general-supply  company  .supply  ,gs), 
requirements  (repair-parts  supply  company , supply  ,gs), 
requirements  (maintenance-company  dsfwd.maintenance.ds). 
requirements  (maintenance  company-dsrear.maintenance.ds), 
requirements  (light-maintenance  company  gs. maintenance. gs). 
requirements(petroleum-supply  company , petroleum, gs). 
requirements  (medium-truck  company. petroleum. gs). 
clean  dbase.  tree(mixed.l).  balance  tree.  tree(mixed.2). 
tree(pure,3)]). 

/'This  procedure  loads  ali  necessary  files  for  the  logistics  planning  system*/ 
load  system  :- 

consult  (estimator),  consult  (scenario), 
consult  (factors),  consult  (demons). 
consu)t(ask).  consult(askl). 
consult  (ask2).  consult  (explain), 
consult  (quest  ions),  consult  (materiel), 
consult  (supply),  consult  (repair). 
consult(supplv2).  consult(ds  inaint  rear). 
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consult(ds_maint_fwd),  consult(gs  maint  light), 
consult  (petrol) ,  consult  (balance) . 
consult(tree),  consult(lists). 

/*The  following  predicates  are  used  to  query  the  user  by  means  of  a  menu  to 
determine  the  force  list  and  the  mission  characteristics  of  the  corps  force.  When 
triggered  the  "demon"  predicate  causes  the  further  questioning  of  the  user  based 
upon  initial  responses  to  the  first  menu.  *  / 
force  list 

ask  which ( [armor  j  series, armor  hseries.mech  j  series, 
mech  h  series  .airborne, air  assault, motorized, light  infantry, 
infantry] )  ,doall(demon)  .nl.nl. 

environmental  factors 

ask  which([low,mid,hi]),  nl,nl, 

ask  which  ([cold,  temperate,  hot  ]),nl,nl. 

/*This  predicate  readjusts  initial  recommendations  so  that  a  more  balanced  force 
can  be  assembled.*/ 
balance  tree:- 

balance (heavy-mater iel  company  .supply  ,gs) . 
balance(supply-and  service  company, supply ,ds) . 
balance(general-supply  company. supply ,gs), 
balance(repair-parts  supply  company  .supply  .gs), 
balance(maintenance-company  dsfwd.maintenance.ds). 
balance(maintenance  company-dsrear . maintenance, ds). 
balance(light-maintenance  company  gs  .maintenance^), 
balance(petroleum-supply  company. petroleum, gs), 
balance(medium-truck  company ,petroleum.gs)  ,nl. 

/*  "prog"  is  equivalent  of  a  Lisp  PROG  construct:  it  does  a  list  of  predicate 
expressions  in  order,  ignoring  whether  they  succed  or  fail,  without  permitting  any 
backtracking  between  them.  *  j 
prog([]). 

prog([P| L] )  not(negcall(P)),  prog(L). 
negcall(P)  not(poscall(P)). 
poscall(P)  :-  call(P). 
poscall(P). 

/'"doall"  is  used  to  ensure  all  possible  calls  to  a  predicate  have  i.e..  it  forces 

backtracking.  '/ 

doall(P)  not(alltried(P)). 

alltried(P)  call( P ) .fail. 
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/*This  file  is  used  to  estimate  the  actual  unit  requirements  of  the  Corps  Support 
Command.  The  "requirements"  predicate  calls  upon  the  rule  base  by  means  of 
the  "setof"  predicate.  Because  of  conflicting  recommendations,  conflict  resolution 
is  provided  by  the  "weighted  avg"  predicate  .  This  predicate  weights  conclusions 
based  upon  whether  they  were  based  on  specific,  general,  or  analagous 
information  about  the  proposed  force  that  is  being  planned.*/ 

/‘This  predicate  collects  the  set  of  all  recommendations  concerning  a  type  of  unit. 
The  set  is  a  lists  of  list:  each  containing  the  number  of  units  that  were 
recommended  and  the  basis  for  the  recommendation.*/ 
requirements(Type  of  Unit.Category,Level) 
setof(X. unit  (Type  of_Unit,X),L). 

write('REQUIREMENTS  ANALYSIS  FOR:  ’),  write(Type  of  Unit).nl.nl, 
write( ’INITIAL  RECOMMENDATIONS:’), nl,writelist(L),nl, 
writefREVISED  LIST:’),nl,  check(L.Ll),  writelist(Ll).nl. 
weighted  avg(Ll,Tvpe  of  Unit, Category, Level, Weighted  Avg).nl. 
writef ’FINAL  RECOMMENDATION:  ’),nl, 
write(’  ’).write( Weighted  Avg).nl.nl. 

/‘This  predicate  deletes  all  recommendations  failing  to  meet  minimum  reqmts.  */ 
check(Initial  List, New  List)  :- 

member  ( [\'alue.minimumj  ,Initial_List) , 
delete2(  Value. Initial  List, New  List). 

/‘This  predicate  determines  the  weighted  average  of  all  unit  recommendations’/ 
weighted  avg(L.Type  of  Unit, Category. Level, Weighted  Avg) 
weighted  sum(L. Weighted  Sum. Divisor). 

Weighted  Avg  is  (  Weighted  Sum  //  Divisor). 

build  troop  list  (Weighted  Avg, Type  of  Unit. Category. Level). 

/‘This  predicate  asserts  a  fact  "troop  list"  for  each  recommended  unit.’/ 
build  troop  list (0.  AnvType.  AnyCategory. Level), 
build  troop  list(Number.Tvpe  of  Unit  .Category. Level) 

N  is  Number  -1. 

asserta(troop  list(Type  of  Unit. Category". Level) ). 
build  troop  list(N,Type  of  Unit. Category. Level). 
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/‘This  predicate  is  used  by  the  "weighted  avg"  predicate  above.  It  sums  the  list 
of  weighted  unit  recommendations.’/ 
weighted  sum([j,0.0). 

weighted  sum([First| Rest] .Total. Divisor):- 

weighted  unit  sum(First,Number,Numberl). 
weighted  sum(Rest. Total  l.Divisorl). 

Divisor  is  Numberl  +  Divisorl.  Total  is  Number  +  Totall. 

weighted  unit  sum([First, general]. First,  1). 
weighted  unit  sum([First, minimum). First, 1). 

weighted  unit  sum([First. analogy], Xumber.3)  Number  is  (First  *  3). 

weighted  unit  sum([First.special], Number. 2)  Number  is  (First  *  2). 


/"The  "tree"  predicate  is  used  to  build  the  command  and  control  structure  of  the 
support  command.  It  takes  all  company  sized  units  and  forms  battalion.  Then  it 
takes  all  battalion  sized  elements  and  forms  the  support  groups.*/ 

/'The  first  "tree"  predicate  structures  the  force  into  battalions  with  the  same 
functional  mission  e.g..  supply.  It  does  matter  what  level  of  support  the  unit 
provides.  Direct  and  general  support  units  may  be  in  the  same  battalion.*/ 
tree(mixed,H) 

bagof(X, Level  ‘troop  list (X.supply, Level), L).keysort(L. LSI), 

bagof(Y. Level  ‘troop  list (Y.maintenance, Level), L2),keysort(L2.LS2). 

bagof(Z, Level  ‘troop  list (Z, petroleum. Level). L3),keysort(L3.LS3). 

mixed(supply.LSl,Ll_out). 

mixed(maintenance,LS2.L2  out), 

mixed(petroleum.LS3.L3  out). 

append(L2  out.Ll  out.L4), 

append(L3  out,L4.L5). 

mixed(spt  grp.L5.L5  out). 

heading) H. Heading),  write) Heading), nl.nl. 

pp(L5  out.5),update2. 

/‘This  "tree"  predicate  structures  the  force  into  battalions  with  the  same 
functional  mission  and  also  separates  direct  support  units  from  general  support 
units.'  / 
tree(pure.H) 

bagof(X. troop  list (X. supply .gs).Ll).keysort(Ll.LlS). 

bagof(X. troop  list (X. supply .ds).L2).keysort(L2,L2S), 

bagof(Y. troop  list(Y.inaintenance.ds).L3).keysort(L3.L3S). 

bagof(Y. troop  list (Y. maintenances). L4).keysort(L4.L4S), 

bagof(Z, troop  list (Z. pet roleum,gs).LP).kevsort)LP.LPS). 

pure(supply,gs.LlS.Ll  out). 

pure(supply.ds.L2S.L2  out). 

pure(maintenance.ds,L3b.L3  out). 

pure(maintenance,gs,L4S.L4  out). 

pure) petroleum, gs.LPS.LPS  out). 

append(Ll  out.L2  out.Lo). 

append(L3  out.L4  out.L6). 

append)  L5.L6.L7). 

appendlLPS  out.L7.L7  out). 

pure(spt  grp.dsgs.L7  out.Lfinal), 

heading(H. Heading),  write) Heading). nl.nl. 

pp(  Lfinal.5).update2. 
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/‘The  "pure"  predicate  forms  direct  or  general  support  battalions  to  serve  as 
parent  units  for  direct  or  general  support  companies  respectively.’/ 
purefType. Level. Ll, New  List) 

span  of  control(Type. Number). 

number  pure  battalions(Type, Level. Number. Numberl), 
create  battalions(Numberl.Type.Bn  List), 
distribute(Ll.Bn  List, New  List). 

/’The  "mixed"  predicate  forms  battalions  on  the  basis  of  functional  missions  such 
as  supply.  Both  direct  and  general  support  units  with  the  same  functional 
mission  can  be  assigned  to  the  same  battalion.’/ 
mixed(Type.Ll.New  List) 

span  of  control(Type. Number), 
number  battalions(Type.Number.Numberl), 
create  battalions( N umberl .T ype.Bn  List ) , 
distribute(Ll.Bn  List, New  List). 

/'The  following  predicate  determines  the  number  of  battalions  needed  to 
command  and  control  a  specified  number  of  companies.’/ 
number  battalions(spt  grp. Number, 2). 
number  battalions(Tvpe.Number.Numberl) 
not (command(Tvpe.  AnyNumber)), 
bagof(X. Level  'troop  list (X. Type. Level),L). 
length(L.Len). 

factor  ( Len  .Nuinber.N  umberl ) . 
asserta  ( command  (Type. Number  1 ) ). 
number  battalions(Type. Number. Numberl) 
command  (Type. Numberl). 

number  pure  bnttalions(spt  grp. dsgs, Number .2). 
number  pure  battalions(Type. Level, Number. Numberl) 
bagof(X. troop  list (X. Type. Level).L). 
length(L.Len). 

factor  (Len,  N  umber.N  umberl ) . 

/'The  "distribute"  predicate  assigns  a  list  of  candidate  units  to  a  parent 
headquarters.  For  example  maintenance  companies  are  distributed  among 
maintenance  battalions.’  / 
distributed  .Bn  List. Bn  List) 
distribute) ,Xj Tail], Bn  List. Bn  List2) 
addfX.Bn  List. Bn  Listl). 
distribute(Tail.Bn  Listl. Bn  List2). 


add(X.Bn  List.BnList  New) 
equal!  Bn  List), 

add  first (X, Bn  List. Bn  List  New). 

add(X.Bn  List, New  Bn  List) 
not  (equal  (Bn  List)), 

first  small  ( Bn  List , [H  ,L] )  ,append(  [X)  .L ,N ) , 
replace) [H,L],[H,N]. Bn  List. New  Bn  List). 


add  first (X, [[Head. Tail]| Bn_List],Bn_List  New) 
append([X]. Tail, New), 

append  ([[Head, New]], Bn  List, BnList  New). 


first  small  ( [X.Y|  L].X) 

second(X.Tl).second(Y.T2). 
length(Tl.N).length(T2,Nl),  Nl  >  N. 
first  small ([X.Y|L],Y) 

second(X,Tl),second(Y,T2). 
length (Tl.N),length(T2.Nl),  N  >  Nl. 
first  small([X.Y| L],Out) 

second(X,Tl),second(Y.T2). 
length(Tl.N).length(T2.Nl),  Nl  =  N. 
first  small([Y] Lj.Out). 

/'This  predicate  creates  battalions  in  order  to  distribute  company  company  sized 
elements  to  the  resulting  battalions.*/ 
create  battalions(0.  1,[]). 

create  battalions(Number,Type,[[Type.[Number]]|  Bn  List]) 

N  is  Number  -  1. 

create  battalions(N,Type.Bn  List). 

/‘These  are  facts  that  determine  number  of  units  per  type  battalion.'/  nf 
span  of  control(supplv.o).  span  of  control(maintenance.5). 

span  of  control(spt  grp. 2).  span  of  control(petroleuin.5) . 

/’These  are  facts  that  determine  which  headings  to  use  as  output  to  inform  the 

user  of  which  algorithm  was  used  to  determine  command  and  control’/ 

heading)  1. 'COMM AND  AND  CONTROL  STRUCTURE  USING  MIXED  ALGORITHM:  ). 

heading(2. 'COMMAND  AND  CONTROL  STRUCTURE  USING  MIXED  ALGORITHM  AFTE 

heading(3. 'COMMAND  AND  CONTROL  STRUCTURE  USING  TURE  ALGORITHM:’). 
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/*The  "balance"  predicate  attempts  to  ajust  the  recommendation  for  a  specific 
type  of  unit  by  increasing  or  decreasing  the  initial  recommendation  to  the  nearest 
multiple  of  the  number  of  battalions.  If  the  adjustment  is  within  an  acceptable 
tolerance  of  20  percent,  the  adjustment  is  made  so  that  battalions  with  the  same 
mission  have  equal  capabilities.*/ 


balance(Type  ofUnit. Category. Level) 

bagof(Tvpe  of  Unit, Level  "troop  list(Tvpe  of  Unit, Category. Level). List), 

length(List. Number  Units).command(Category, Number  Bns). 

closest  multiple(Number  Bns.Number  Units, Ans), 

check_threshold(Number  Units. Ans.Ansl). 

adjust(Ansl.Tvpe  of  Unit. Category, Level). 

revisions( Ansi, Number  Units, Type  of  Unit). 


check  threshold(Number  Units, Ans, Ans) 
Ans  >  0. 

Max  Change  is  (Number  Units  *  0.25), 
Ans  =*■  Max  Change. 


check  threshold(Number_Units,Ans,Ans) 
Ans  <  0. 

NewAns  is  (Ans  *  -l). 

Max  Change  is  (Number  Units  *  0.25). 
NewAns  =<  Max  Change. 


check  threshold(Number  Units. Ans.0). 


revisions(0, Number  Units.Type  of  Unit). 
revisions( Ans. Number  Units.Type  of  Unit) 

New  Number  Units  is  (Ans  +  Number  Units), 
writefThe  old  number  for  ').  write(Type  of  Unit). 
write(‘  was  changed  from  ‘).  write(Number  Units). 
write('  to  ').  write(New  Number  Units).write('  .’).nl. 
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closest  multiple(Number  Bns. Number  Units. Ans) 

Number  Units  =<  Number  Bns.  Ans  is  (Number  Bns  -  Number  Units), 
closest  multiple(Number  Bns.NumberUnits.O) 

R  is  (Number  Units  mod  Number  Bns).  R  =  0. 
closest  multiple(Number  Bns. Number  Units. Ans) 

Lb  is  ((Number  Units  //  Number_Bns)  *  Number  Bns), 

Ub  is  (((Number  Units  4-  Number  Bns)  //  Number  Bns)  *  Number  Bns). 
Dl  is  Number  Units  -  Lb.  D2  is  L’b  -  Number  Units, 
min2(Dl.D2,Ans). 

min2(Dl.D2.-Dl):-  Dl  <  D2  . 
min2(Dl.D2.D2)  Dl  >  =  D2. 

adjust  (0. Type, Category, Level)  !. 

adjust(Adj  Qtv. Type, Category, Level) 

Adj  Qty  <  0,  Vl  is  Adj  Qtv  -I-  1, 
retract  (troop  list  (Type. Category. Level)), 
adjust  (Vl, Type,  Category.  Level). 

adjust  (Adj  Qty. Type.  Category,  Level) 

Adj  Qty  >  0.  Vl  is  Adj  Qty  -  1, 
asserta(troop  list  (Type. Category  .Level)), 
adjust  (Vl, Type, Category, Level). 
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/’The  "pp"  predicate  prints  the  hierarchical  diagram  for  the  support  group.  It 
accepts  the  representation  of  the  support  group  as  a  list  of  lists.  It  indents  for 
each  level  of  the  tree.*/ 


pp([H|T],I)  :-  !,  J  is  I  +  5.  pp(H.J),  ppx(T.J),  nl. 


pp(X.I)  .- 

not(member(X,[maintenance.supply. petroleum, spt  grp])), 
not(number(X)),  tab(I). 

retract(fb(unit,L,Name)),  write(L),write(’-‘),  write(X), 

NL  is  L  +  1,  asserta(fb(unit.NL,Name)),nl. 


PP(spt  grp, I) 

fb(spt  grp, 2. ’SPT  GRP1).  tab(I).  write(2),  write(’-’), 
write(’SPTGRP'),  update2,nl. 


pp(X.I) 

tab(I).  retract(fb(X.L,Name)). 
write(L).  write('-').  write(Name). 

NL  is  L  +  1.  asserta(fb(X.NL.Name)),nl. 


pp(X.I)  tab(I).  number(X).  nl. 


ppx([] .  )  retract(fb(unit.L.’  ’)),  asserta(fb(unit,l.'  ')). 
ppx([H|T].I)  pp(H.I).  ppx(T.I). 


update2 

retract (fb (maintenance. Ll.’MAINT  BN’)), 
asserta(fb(maintenance,l . ’MAINT  BN’) ) , 
retract (fb(supply,L2,’SUPPLY  BN’)), 
assert a(fb(supply,l, ’SUPPLY  BN’)). 
retract(fb (petroleum. L3. 'PETROL  BN')), 
assert  a  (fb(petroleum,l. 'PETROL  BN')). 
retract(fb(spt  grp. L4, 'SPT  GRP')). 
asserta(fb(spt  grp, 1. ’SPT  GRP’)). 
retract(fb(unit.L5.'  ’)).  asserta(fb(unit.l,'  ')). 


fb(unit.l.’  '). 

fb  (maintenance.!. 'MAINT  BN'). 
fb(supply.l. ‘SUPPLY  BN'), 
fbfpetroleum.l.  PETROL  BN  ). 
fb(spt  grp. 1. 'SPT  GRP'). 


/*The  following  rules  are  for  selection  of  Supply  and  Service  Companies.’/ 

unit(supply-and  service  company, [Number  of  Units.specialj) 
scenario(l). 
number  divisions(N) . 

Number  of  Units  is  N  *  3. 

unit(supply-and  servicecompany, [Number  of  Units.specialj) 
scenario(2), 
number  divisions(N). 

Number  of  Units  is  N  *  2. 

unit(supply-and  service  company, [Number  of  Units, special]) 
scenario(3), 
number  divisions(N) . 

Number  of  Units  is  N  *  1. 

unit(supply-and  service  company. [Number  of  Units.specialj) 
scenario(4), 
number  divisions(N). 

Number  of  Units  is  N  *  1. 

unit (supplv-and  service  company, [Number  of  Units, minimum]) 
heavy  corps, 
number  divisions(N). 

Number  of  Units  is  N  ’  1. 

unit  (supply-and  service  company, [Number  of  Units, minimum]) 
light  corps, 
number  divisions(N). 

Number  of  Units  is  (N  //  2). 

unit(supplv-and  service  company, [Number  of  Units. analogy] ):- 
number  divisions(N). 

N  :•  1,  N  <  5, 

Number  of  Units  is  8. 

unit(supplv-and  service  company, [Number  of  Units. analogy] ):- 

number  divisions^))  j 

N  4.  N  <'  8.  * 

Number  of  Units  is  16.  i 

1 

I 
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unit(supplv-and  service  company, [Number  of  I'nits.generalj)  :- 
corps  _st  rengt  h  ( X ) . 

Strength  is  (X  //  3). 
factor(Strength.8, Number  of  Units).!. 

unit(supplv-and  service  battalion, [Number  of  I’nits.generalj)  :- 
Number  of  Units  is  2. 

/*The  following  rules  are  for  selection  of  General  Supply  Companies.*/ 

unit  (general-supply  company, [Numberof  Units.special]) 
scenario(l). 
number  divisions(N), 

Number  of  Units  is  (N  *  1). 

unit  (general-supply  company, [Number  of^Units  .special])  :- 
scenario(2). 
number  divisions(N). 
factor(N.2. Number  of  Units). 

unit  (general-supply  company,  [Number  of  Units. general])  :- 
number  divisions (N), 
factor(N. 3, Number  of  Units). 

unit  (general-supply  company. [Number  of_Units.  analogy])  :- 
number  divisions(N). 

N  >  2.  N  5.  Number  of  Units  is  4. 

unit(general-supplv  company, [Number  of  Units.analogy])  :- 
number  divisions(N). 

N  4.  N  8.  Number  of  Units  is  8. 

unit  (general-supply  company, [2,minimum] )  :-  heavy  corps. 

unit  (general-supply  company, [l.minimum])  :-  light  corps. 

unit  (general-supply  company. [Number  of  I’nits.generalj) 
corps  strength(Total) .  factor(rations.Nl). 
factor(misc  equip. N2).  factor(barrier  materiel. N3). 
factor  (personnel  items.  N4).  R  is  (NI  +  N2  +  N3  -+■  N4). 

General  Supply  Reqmnt  is  ((R  ’  Total)  //  2). 
factor(General  Supply  Reqmnt. 350. Number  of  Units).!. 


71 


/'The  following  rules  are  for  selection  of  Heavy  Materiel  Companies.'/ 

unit  (heavy-materiel  company. [2,special]) 
scenario(l)  . 

unit (heavv-materiel  company. [l.special])  :- 
scenario(2)  . 

unit  (heavy-materiel  company. [l.special])  :- 
scenario(3). 

unit(heavv-materiel  company. [l.special])  :- 
scenario(4)  . 

unit  (heavv-materiel  company, [l, analogy])  :- 
light  corps  . 

unit  (heavv-materiel  company. [2, analogy])  :- 
heavy  corps  . 

unit  (heavv-materiel  company, [l, minimum]). 

unit  (heavv-materiel  company. [Number  of  Units, general])  :- 
corps  strength  (Number). 
factor(Number, 85. Number  of  Units).!. 

/‘The  following  rules  are  for  selection  of  Repair  Parts  Companies.'/ 

unit  (repair-parts  supply  company. [1. minimum]). 

unit  (repair-parts  supply  company. [1. analogy]). 

unit  (repair-parts  supply  company, [Number  of  Units.general]) 
fact  (no  gs  repair) .factor(  10.3. Number  of  Units). 

unitfaircraft  missile  repair-parts  company. 1). 


/'The  following  rules  are  for  selection  of  Maintenance  Companies. * / 

unit(maintenance  companv-dsrear. [5. analogy]) 
number  divisions) N). 

X  2.  N  ■  5  . 

unit(maintenance  company-dsrear. [Number  of  Units.special])  :- 
scenario)  1). 
number  divisions (X). 

Number  of  Units  is  N  '  1. 

unit(rnaintenance  companv-dsrear. [Number  of  Units.special]) 
scenario(2). 
number  divisions) N), 
factor(N. 2. Number  of  Units). 

unit  (maintenance  companv-dsrear.  [Number  of  Units.special]) 
scenario(3). 
number  divisions) N). 
factor(N. 2. Number  of  Units). 

unit  (maintenance  companv-dsrear. [Number  of  Units.special])  :- 
scenario)-!), 
number  divisions) N). 
factor)N. 2 .Number  of  Units). 

unit  (maintenance  company-dsrear.  [2.  minimum] ). 

unit  (maintenance-company  dsfwd.jlO. analogy])  :- 
number  divisions(N). 

N  2.  N  5  . 

unit(maintenance-company  dsfwd. [Number  of  Units.special])  :- 
scenario)  1 1. 
number  divisions) N). 

Number  of  Units  is  N  '  2. 
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unit  (maintenance-company  dsfwd. [Number  of  Units.special  )  :- 
scenario(2), 
number  divisions) N). 

Number  of  Units  is  N  . 

unit  (maintenance-company  dsfwd. [Number  of  Units.special  )  :- 
scenario)  3). 
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number  divisions(N). 

Number  of  Units  is  N. 

unit  (maintenance-company  dsfwd,  [Number  of  Units.speeial; )  :- 
scenario(4), 
number  divisions(N), 

Number  of  Units  is  N. 

unit  (maintenance-company  dsfwd,  [4. minimum]). 

unit  (light-maintenance  company  gs,[  10.  analogy])  :- 
number  divisions(N). 
heavy  corps. 

N  >  2?N  *  5  . 

unit  (light-maintenance  company  gs, [5, analogy] )  :- 
number  divisions(N). 
light-corps. 

N  2.  N  -  5  . 

unit(light-maintenance  company  gs. [Number  of  Units.speeial]) 
scenario)  1). 
number  divisions(N). 

NumbeT  of  Units  is  N  ‘  2. 

unit(light-maintenance  company  gs. [Number  of  Units.speeial]) 
scenario(2), 
number  divisions) N). 

Number  of  Units  is  N  . 

unit  (light-maintenance  company  gs, [Number  of  Units.speeial]) 
scenariolS). 
number  divisions) N). 

Number  of  Units  is  N. 

unit  (light-maintenance  company  gs. [Number  of  Units.speeial] ) 
scenario|4). 
number  divisions(N). 

Number  of  Units  is  N. 

unit(light-maintenance  company  gs. [2. minimum] ):-  light  corps. 

unit(light-maintenance  company  gs. [4. minimum  ):-  heavy  corps 
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/‘The  following  rules  are  for  selection  of  Petroleum  Companies*/ 

unit(petroleum-supplv  company. [Number  of  Cnits. minimum])  :- 

heavy  corps.number  divisions  (Number  of  Units).  ‘ 

1 

t 

unit(petroleum-supplv  company. [Number  of  Units. minimum))  1 

light  corps.number  divisions(N). 

Number  of  Units  is  (N  //  2).  ( 

1 

j 

unit  (petroleum-supply  company, [Number  of  Units.generalj)  - 
corps  strength(X). 
factor  ( pet  roleum.Y). 
days  of  supply (Z). 

Total  Gallons  is  ((X  *  Y  *  Z  ‘  300)  //  2). 
factor(Total  Gallons. 1000000. Number  of  Units).!. 

days  of  supply)  15). 

unit ( medium- 1 ruck  company. [2. analogy] ). 
unit(medium-truck  company. [Number  of  Units. minimum])  :- 

bagoffX. troop  list  (petroleum-supply  company . petroleum.gs). L) . 
length(L.Len).  factor(Len. 5. Number  of  Units). 

unit  (medium-truck  company. [Number  of  Units.generalj)  :- 
corps  strength(X). 
factor  (pet  roleum.Y). 

Total  Daily  Gallons  is  ((X  '  Y  ’  300)  //  2). 
factor(Total  Daily  Gallons, 450000. Number  of  Units).!. 
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/’The  following  rules  are  used  to  determine  the  applicable  scenario*/ 

scenario)  1) 
fact(hi). 
heavy  corps.!. 

scenario)  2) 
fact(hi). 
light  corps.!. 

scenario)  3) 
fact  (mid), 
heavy  corps.!. 

scenario)  4 1 
fact(mid), 
light  corps.!. 

scenario)  5) 
fact(lo). 
heavy  corps.!. 

scenariolG) 
fact(lo). 
light  corps.!. 

heavy  corps  > 

bagof)  X  .heavy  ( X )  .L )  .sum)  L.S ) . 
bagoffY. light  (Y).Ll). sum)  Li.Sl). 
s  -  SI. 

light  corps 

bagof(X.heavy(X).L).sum(L.S  |. 
bagof) ^  .light (Y).Ll ). sum) Ll.Sl ). 

S  SI. 

heav\  corps  > 

heavy |  X  | .not  (light  ( Y ) ) . 

light  corps 

light(X).  not(heavy)X) ). 
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/‘This  file  provides  explanations  to  assist  users  in  answering  questions'/ 
/‘that  they  may  not  fully  understand  '/ 


explainlheavy  corps) 

writefA  heavy  corps  force  is  one  that  consists  ’),nl. 
write('of  armor  and  mechanized  infantry  divisions. *).nl. 
write) ’The  force  may  have  other  types  of  divisions'). nl. 
write) ’but  the  majority  of  its  divisions  should  be’J.nl, 
writefarmor  and  mechanized  infantry.’). 

explain(light  corps) 

write) "A  light  corps  force  is  one  that  consists  of).nl. 
write('of  light,  airborne,  or  airmobile  divisions.'). nl. 
write)  The  force  may  have  other  types  of  divisions'). nl. 
write)  but  the  majority  of  its  divisions  should  be').nl. 
write) 'light,  airorne.  or  airmobile  divisions.'). 

explain! developed  country) 

write) 'A  developed  nation  is  a  nation  that  has  an').nl. 
write) ‘industrialized  economy.  The  term  implies’). nl. 
write!  the  nation  has  a  developed  infrastructure'). nl. 
write) Of  roads,  rail,  airports,  etc..  ). 

explain! underdeveloped  country) 

write) 'An  underdeveloped  nation  is  one  in  which'). nl. 
write) 'industrialized  characteristics  such  as'J.nl. 
write) 'good  road  and  rail  facilities  and  aiport' fill, 
write) 'are  not  present.'). 

explain) independent  force) 

write)  An  independent  force  is  one  in  which  thefnl. 
write) ‘corps  is  expected  to  deploy  and  conduct  ).nl. 
write) 'conduct  combat  operations  without  any  ),nl. 
write)  accompanying  friendly  forces.’). 

explainlrommz ) 

writefA  communications  zone  (commz)  exists  ‘ ) .11 1 . 
write) 'or  will  exi*t  if  a  theater  army  and  its’fnl. 
write)  associated  support  units  will  be  present  ).nl. 
write) 'in  the  area  of  operations  providing  support ')  .nl. 
write)  to  corps  support  activities. '). 
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explain  (strength) 

write) 'The  personnel  strength  extimate  should  be  the'j.nl. 
write)  cumulative  strength  for  all  divisional  and  all  ),  nl. 
write)  nondivisional  forces  in  the  proposed  corps  force.  ). 

explain) number  of  divisions) 

write)  The  number  of  divisions  should  only  include  the‘).nl. 
write)  actual  number  of  divisions  or  division  equivalents'),nl. 
write)  contained  in  the  actual  corps  force.  ). 

explain) non  divisional  strength) 

write)  Nondivisional  strength  should  only  include  the  ).nl. 
write)  personnel  strengths  of  the  nondivisiona  units  in  the  corps. '). 
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/ 4 This  file  contains  a  series  of  ask  predicates  that  will  only  be'/  j 

/’triggered  based  upon  a  certain  force  composition  provided  by  the*/  I 

/’the  user  during  a  previous  menu  session*/  j 

demon  fact  (armor  j  series).  i 

write('Please  enter  the  number  of  "J"  series  armor  divisions?'). 

read(Ans).  1 

Strength  is  17  *  Ans.  j 

asserta(strength(Strength)). 
assert  a(  heavy  ( Ans )) . 

demon  fact  (armor  h  series). 

write)  Please  enter  the  number  of  "H"  series  armor  divisions?  ), 
read)  Ans). 

Strength  is  19  *  Ans. 
asserta(st  rength(Srrength) ). 
asserta(heavv(  Ans) ) . 

demon  factlmech  j  series). 

write)  Please  enter  the  number  of  "J"  series  merh  divisions?'), 
read  (Ans). 

Strength  is  17  *  Ans. 
assert  a  (strength!  Strength) ). 
assert  a)  heavy!  Ans) ). 

demon  factlmech  h  series). 

write) 'Please  enter  the  number  of  "H"  series  merh  divisions'’' |. 
read)  Ans). 

■strength  is  19  '  Ans. 
assert  a)  st  rengt  h  ( St  rengt  h ) ) . 
assert  a)  heavy  ( Ans)). 

•lemon  fact  (airborne). 

write)  Please  enter  the  number  of  airborne  divisions?  ), 
read  I  Ans ) . 

Strength  i-  17  '  Ans. 
assert  a  ( st  rengt  hi  St  rengt  h) ) . 
asserta(light  (  Am )  I . 

demon  fact  i  motorized),  write! 'Please  enter  the  number  of  motorized  divisions?'), 
read  (Ails  j.  Strength  is  14  '  Ans. 
assert  a  ( st  rengt  h  I  St  rengt  h) ) . 
asserta) light  ( Ans ) ) . 
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demon  fact  (air  assault). 

write)  Please  enter  the  number  of  motorized  divisions?  ). 
read(Ans).  Strength  is  19  *  Ans. 
assert  a  ( st  reng  t  h  ( S  t  rengt  h ) ) . 
asserta)  light  (Ans)). 

demon  fact ( light  infantry). 

write)  Please  enter  the  number  of  light  infantry  divisions?'), 
read(Ans).  Strength  is  10  *  Ans. 
as  serta(strength)  Strength)), 
assertaf  light)  Ans)). 

demon  fact  (infantry). 

write)  Please  enter  the  number  of  standard  infantry  divisions?'), 
read)  Ans). 

Strength  is  16  '  Ans. 
assert  a  I  strength)  >:  rengt  h) ) . 
asserta)  light  I  Ans) ) . 

demon 

bagof)  X .heavy I X ) ,L ) .sum I  L.S ) . 
bagof) X. light  (X  ).L  1  ).sum(  Ll  .SI ). 

S3  is  (S  -s  SI). 

assert  a)  number  divisions)  S3)), 
demon 

bagof)  X  .heavy  I X )  .L )  .sum  ( L.S). 
asserta) number  divisions) S) ) 

demon 

bagof)  X.  light  (X).L).sum(L.S). 
assert  a  |  number  divisions)  S) ) . 

demon  - 

bagof)  St  rengt  h  .strength)  St  rengt  h  I.L  I . 

sum(L.(  orj>-  Strength),  assort  a  (corps  st  rengt  h)  Corps  Strength) 
sum)  .()i 

sum)  Xj  L  .Totall  'um(L.Total2l. Total  is  Total?  X. 
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/ +  This  file  contains  planning  factors  which  are  adjusted  based  upon'/ 
/*the  operational  characteristics  of  the  particular  scenario’/ 

factor(rations.4). 

factor(misc  equip. 5)  scenario(l).not(fact(cold)). 

factor(misc  equip.o)  scenario(2),not(fact(cold)). 

factor(inisc_equip,4)  scenario(3). 

factor (misc  equip.4)  scenario(4). 

factor (inisc  equip.4)  scenario(5). 

factor(misc  equip.4)  scenario(G). 

factor(misc  equip.6)  scenario(l).  fact(cold). 

factor(misc  equip.6)  scenario(2).  fact(cold). 

factor(misc  equip.4)  not(scenario(X)). 

factor(petroleum.54)  scenario)  1). 

factor(petroleum.47)  scenario(2). 

factor) petroleum. 47)  scenario(3). 

factor(petroleum.40)  scenario(4). 

factor(petroleum.40)  scenario(5). 

factor(petroleum.34)  scenario(G). 

factor(petroleum.47)  not(scenario(X)). 

factor(ammo.35)  scenario)  1). 
factor(ammo.25)  scenario(2). 
factor(ammo.30)  scenario(3). 
factor(ainmo.25)  scenario(4). 
factor(ammo.25)  scenario(5). 
factor(ainmo.20)  scenario(6). 
factor(amrno.30)  -  not(scenario)X) ). 

factor) barrier  materiel. 8). 

factor(personnel  items. 3). 

factor(major  items. 18)  scenario!  1). 

factor(major  items. 15)  scenario(2). 

factor(major  items. 15)  scenario(3|. 

factorfimjor  items. 12)  scenario(4  ). 

fact  or  (major  items. 12)  scenario|5). 

factor(major  items. 9)  scenario(G). 
factor(major  items. 15)  not(scenario(X)). 


factor(medical  items, 1)  not(scenario(l)). 

factor(medical  items. 2)  scenario(l). 

/'The  following  procedures  compute  the  gross  tons  of  supplies  needed'/ 
/‘per  day  in  the  corps  area.'/ 

calculate 

corps  strength(N). 
factor(X,Nl), 

Requirement  is  ((X  *  Nl)//2), 
write('The  daily  force  requirement  for  ), 
write(X).write(’  is:  ’). 

write(Requirement).  write("  short  tons'). nl. 


I 
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/’'The  following  predicates  are  used  to  query  the  user  by  means  of  a  menu  to 
determine  the  force  list  and  the  mission  characteristics  of  the  corps  force. 

When  triggered  the  "demon"  predicate  causes  the  further  questioning  of  the 
user  based  upon  initial  responses  to  the  first  menu.  */ 

force  list 

ask  which( [armor  j  series.armor  h  series. mech  j  series, 
mechh  series. airborne,air  assault.motorized, light  infantry, 
infantry] )  .doall(demon) . 

environmental  factors 
nl.nl. 

ask  which([low.mid.hi]), 
nl.nl. 

ask  which  ([cold. temperate. hot]). 
nl.nl. 

/'This  file  contains  question  codes  used  by  the  ask  predicate.  In  particular'/ 
/‘this  file  has  questioncodes  applicable  to  logistics  force  planning.  These'/ 
/'questioncodes  allow  terminal  prompts  to  obtain  specific  information  con-  */ 
/'cerning  the  characteristics  of  a  particular  corps  force  so  that  logistical  '  / 
/'unit  requirements  can  be  determined'/ 


/'The  following  questioncodes  help  determine  the  appropriate  scenario4/ 

questioncode(commz.Ts  a  communications  zone  established  in  the  area’), 
questioncode) developed  country.  ’Is  the  area  of  operations  in  a  developed  country'), 
questioncodej independent  corps,  'Is  the  force  an  independent  corps'). 
questioncode(cold.'Is  the  force  to  be  depoloyed  to  a  cold  environment’). 
questioncode(temperate,’Is  the  force  to  be  deployed  to  a  temperate  climate'). 
questioncode(hot.'Is  the  force  to  be  deployed  to  a  hot  environment'), 
quest ioncode(low. 'Is  the  force  to  be  engaged  in  a  low  intensity  conflict'). 
questioncode(mid.'Is  the  force  to  be  engaged  in  a  mid  intensity  conflict'), 
quest ioncode(hi.  Is  the  force  to  be  engaged  in  a  hi  intensity  conflict'). 

/  'The  following  question  codes  assist  in  determining  force  composition'/ 
questioncodef armor  h  series. 'Are  "H"  series  armor  divisions  in  the  force'), 
quest ioncode( armor  j  series.  Are  "J"  series  armor  divisions  in  the  force  ), 
questioncodefmech  h  series.  Are  "H”  series  mech  divisions  in  the  force"). 
questioncode(mech  j  series.  Are  ".I"  series  mech  divisions  in  the  force'). 


questioncode(infantrv.’Are  standard  infantry  divisions  in  the  force'). 
questioncode(airborne,’Are  airborne  divisions  in  the  force’), 
quest ioncode (air  assault. ’Are  air  assault  divisions  in  the  force’). 
questioncode(motorized.’Are  motorized  divisions  in  the  force'). 
questioncode(light  infantry. ’Are  light  infantry  divisions  in  the  force'). 


/*  The  following  rules  assist  question-asking.  The  "ask”  predicate  *  / 

/ '  asks  the  user  a  question.  providing  extra  explanation  if  the  user  * / 

/'  types  a  question  mark,  and  returns  the  answer  (after  caching  it).  *  / 

/’  The  "questioncode"  and  "explain"  predicates  must  be  provided  by  * / 

/’  the  programmer:  the  first  decodes  questions,  and  the  second  provides  * / 
j'  additional  information  for  particular  questions  when  the  user  has  */ 

/’  trouble  understanding.  The  "askif1'  predicate  handles  yes/no  questions:  */ 
/’  it  succeeds  if  the  user  answers  positively,  fails  if  the  user  answers  T/ 

/  ’  negatively,  and  prompts  if  the  user  answers  anything  else.  */ 

/’  Warning:  do  "abolish(asked.2))"  to  erase  memory  before  a  new  problem.  */ 

askif(Qcode)  ask(Qcode.A).  positive  answer(Qcode,A). 
askifnot(Qcode)  not(askif(Qcode)). 
positive  answer (Qcode, A)  affirmative(A). 

positive  answer(Qcode.A)  not(negative(A)).  not(affirmative( A)). 

write('Please  answer  yes  or  no.‘).  read(A2).  retract(asked(Qcode.A)). 
asserfa(asked(Qcode.A2) ).  affirmative)  A2). 
ask(Qcode.A)  asked(Qcode.A). 

ask(Qcode.A)  not(asked(Qcode.A)).  questioncode(Qcode.Q),  write(Q). 

write)'?  ').  read(A2).  ask2(Q,Qcode.A2.A). 
ask2(Q.Qcode,’?'.A)  explain(Qcode).nl.ask)Qcode.A). 
ask2(Q,Qcode.A,A)  not(A='?‘),  asserta(asked)Qcode.A)). 
affirmative  (ves). 
affirmative(y). 
affirmative(ye). 
affirmative(right). 
affirmative(ok). 
affirmative(uhhuh) . 
negative(no). 
negative(n). 
negative(not). 
negative(never). 
negat  ive)  impossible ) . 
negative(haha). 


ask_which([A.B,C.D.E.F,G,H.I| L]) 

screen  '«k_which([A.B.C.D.E.F.G,H.I], [A. B.C.D.E.F.G.H.I]) 
ask  which(L). 

ask  which([J). 

ask  which (L) 

length(L,X).  N  <  10.  X  >  0. 
screen  ask  which  (L.L). 

screen  ask  which([Xj L].L2) 
length  (L.X). 
length(L2,X2). 

X3  is  N2  -  N. 
write(X3), 
write)  Y). 

questioncode(X.Q). 

write(Q). 

write('?‘). 

nl. 

assert  a  ( asked  ( X  .no) ) . 
screen  ask  which (L.L2). 

screen  ask  which([].L2) 

write(’Give  number  of  only  question  whose  answer  is  yes.  ). 
read(AL). 

create  facts) AL.L2). 
nl. 

create  facts([X|  L).L2) 
item(N.L2.I). 
assertz(factfl)), 
retract  (asked)  I, no)), 
asserta(asked)I.yes)). 
create  facts(L.L2). 
create  facts) [X]  L].L2) 
not(item(X.L2.I) ). 
create(facts(L.L2) ). 
create  facts ( [) ,L2 ) . 

item(l.[X|  Lj.X). 
item(X.[X|  Lj.I) 

X  -•  1.  X2  is  X  -  1.  item(X2.L.I). 
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